"Magnus Hagander" <mha@sollentuna.net> writes:
> Agreed. I definitly vote for backing out the patch so we don't block the
> release. If we find the problem we put it back in before release, but if
> it takes a while we just wait for 8.2.
After digging in the Microsoft documentation a little bit, I think I
see the problem: we implement SIGALRM timeouts by means of a "waitable
timer", and the system's action when the timeout expires is:
When a timer expires, the timer is set to the signaled state. If the timer has a completion routine, it is
queuedto the thread that set the timer. The completion routine remains in the APC queue of the thread until
thethreads enters an alertable wait state. At that time, the APC is dispatched and the completion routine
iscalled.
In other words, since the main thread is the one that set the timer,
it has to run the completion routine (which just sets the signal flag).
The completion routine will never be run if the main thread is in a
tight loop with no kernel calls. In particular, it was the frequent
execution of WaitForSingleObjectEx via CHECK_FOR_INTERRUPTS that allowed
this technique to work at all.
Isn't there some way we can get the timer completion routine to be run
by the signal thread instead? This coding seems pretty unreliable to me
even without QQ's patch.
regards, tom lane
