Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance

["Magnus Hagander" <mha(at)sollentuna(dot)net>]

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