Magnus Hagander wrote:
> > Magnus Hagander wrote:
> > > Here's an updated version of the proposed win32 signals
> > code, with the
> > > following main changes:
> >
> > One small possible revision to consider: As I read the code,
> > all manipulation to pg_signal_queue is inside a
> > CriticalSection, and it is only set (> 0) when there are
> > pending signals.
> >
> > ISTM that pg_queue_signal can abort without calling
> > QueueUserAPC pg_signal_queue is already set. This will keep
> > the dispatch function from getting called extra times.
> > Paranoia statement
> >
> > pg_signal_queue = 0;
> >
> > could possibly be added at the end of the dispatch.
>
> No, I don't think it can't. Consider delayed signals. When leaving the
> dispatch function, pg_signal_queue may very well be != 0. Only
> (pg_signal_queue & ~pg_signal_mask) should be zero.
Yep...my bad.
> Also, I think it's best if the mask is checked upon signal *delivery*,
> not queueing. The signal could be blocked when delivered and
non-blocked
> on delivery. If we never queue a APC in this case, the signal will be
> lost. But we *could* do the check in pg_signal_queue, but then against
> (pg_signal_queue &~ pg_signal_mask).
Right...that is safer. I still think there may be a more sophisticated
check in there...if any executable signal is already pending, then you
can count that you are either in a dispatch or that dispatch is already
queued.
Merlin