Re: Win32 signal code - first try

> > > 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.

Yeah, I think that's unnecessarily complicated.

> 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.

Actually, no. If we keep a separate variable that just is zero if no
signals or != 0 for any signals whatsoever, we only need a *single
compare instruction* in the loop. That should be much faster than
WaitForSingleObjectEx() - things like argument checking etc are all
gone.
The loop inside the critsec only has to run when there are actual
signals to deliver, which should be a very very small fraction of the
time.

> 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.

Those are good points. They stand against the fact that putting the Ex()
functions should be considerably slower than a simple compare
instruction.

If we do lots of polling, this might be noticeable. The question then
becomes how often we need to poll.

I'll try to put something together with QueueUserAPC() and a WaitFor()
thing in the polling macro (assuming my net connectino at home has been
fixed, I'll get something out during the weekend). We can always change
it later if we find it's a performance bottleneck.

//Magnus