Claudio Natoli wrote:
> > A thought there. If we go with the "select loop" version you had
tried
> > out and just poll (select() with short timeout, poll, loop..), do we
> > actually *need* the APCs *at all*? Or should we go with a
pure-polling
> > solution? (With signals delivered on a separate thread as we
discussed,
> > of course) The only advantage we gain by the APCs is that they will
stop
> > the "Ex functions", no? (It's not much extra code to put it in
there,
> > but if we don't need it..)
>
> Hmmm, not sure. Possibly we can, although it depends on where else we
> might
> end up needing to "wait". I'd be unreluctant to undo your good work on
> this
> until we are sure it is safe to...
There are a couple advantages to using QueueUserAPC for the signal
delivery. There are two alternatives that I see, SignalObjectAndWait,
and a looping array index.
The problem with SignalObjectAndWait is that it a. does not queue (all
waiting threads released at once) and b. has more complicated threading
issues...so I would tend to discount this option. If it was necessary
to queue the signals FIFO, we would have to set up the FIFO stack.
A looping array counter is better, because now everything important runs
in the main thread. Basically, during each poll the backend runs a
tight loop inside a critical section to check if there are any pending
signals. In fact, this is slightly faster that a WaitForSignalObjectEx,
but involves more code.
That's the crucial point for me: QueueUserAPC is simpler; most of the
signal utility routines will be just a couple lines of code. This will
make debugging less of a pain and be easier to test. Plus, the OS will
do the queuing, which is the most vulnerable part of the code to bugs
and other problems...no loops! My intuition tries to keep me away from
loops wherever possible.
Merlin