Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance

> > In the spirit of incremental improvement ... I've taken Magnus'
> > version and added the proposed change to re-enable
> Qingqing's patch by
> > skipping WaitForSingleObjectEx altogether in the
> CHECK_FOR_INTERRUPTS code path.
> > I also removed WaitForSingleObjectEx in
> pgwin32_poll_signals(), which
> > AFAICS should be just like CHECK_FOR_INTERRUPTS. I think
> this is what
> > we are proposing to actually apply to 8.1beta4. I can't test it
> > though, so please check it over...
> >
> Questions:
>
> Are we asserting that
>
> UNBLOCKED_SIGNAL_QUEUE() != 0
> then
> WaitForSingleObjectEx(0)==WAIT_OBJECT_0
>
> If so, we can put this assertion in. Seems there is some
> race. In pg_queue_signal(), we do it like this:
>
> enter_critical_section();
> mask the signal;
> leave_critical_section();
> SetEvent();
>
> That is, we may detect the value first before we got event.
> So at least the above assertion is not correct. This may
> cause other problems, just for a quick feedback.

Actually, wasn't the latest that we *only* use the event object in order
to "break out" of blocking operations in the socket code? And only use
checking + checking in critical seciton to deliver? In this case, it
shouldn't matter when the event is set as long as it's always set
*after* we update the values.

Meaning that we'd have for the check just:
UNBLOCKED_SIGNAL_QUEUE()
enter_critical_section()
UNBLOCKE_DSIGNAL_QUEUE() again
leave_critical_section()

and when we use the event to break out, tha'ts just a WFSO before that
whole cycle runs.

(Don't have the code around right now, and it's getting a bit late after
a long day, so forgive me if I'm missing something obvious in that
reasoning :P)

//Magnus