"Magnus Hagander" <[EMAIL PROTECTED]> 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 queued to the thread
that set the timer. The completion routine remains in the APC
queue of the thread until the threads enters an alertable wait
state. At that time, the APC is dispatched and the completion
routine is called.
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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
