Re: Win32 signal code - first try

Merlin Moncure wrote:
> To summarize my opinion of how things should go:
> 1. Named pipe server creates new thread on receipt of signal
[snip]

Forgive me for taking your solution, and suggesting a very similar, but
IMNSHO, a somewhat more generic/future-proof solution:

1) Named pipe server creates new thread on receipt of signal
2) New Thread issues WriteFile (thereby immediately informing the signaller
of the receipt of the signal)
    - or, better and safer yet, get the pg_signal_thread_proc [ie. the Named
pipe server] to do it following the creation of this new thread
3) New Thread then enters a while(1) loop of the following sort:
       WaitForSingleObject(someMutex,INFINITE);
     if the current signal is blocked

SignalObjectAndWait(someMutex,someManualEvent,INFINITE,FALSE);
       else {
            Release(someMutex...);
        QueryUserAPC(...);
            ExitThread(...);
       }
4) Changes to the current signalling state would simply
PulseEvent(someManualEvent)

[Note: we'd need to protect the "current signal is blocked" test with the
existing Critical section (faster, but haven't convinced myself this is
completely safe), or change all the existing crictical section calls to be
locks/releases on the above "someMutex" (slower, but bulletproof)]

However, there is nothing in either my nor your suggestion that guards
against the following race-condition. Essentially, nothing is stopping the
APC actually being run at some later time (because, as you'll note, we've
only stopped the queuing of the APC, not the actual execution) when it
should be blocked.

AFAICS, a simple solution to this exists. Execute a SleepEx(0,TRUE)
(strictly, whatever __pg_poll_signals ends up being) on entry to any
function that changes the current signalling state. That way, we'll
guarantee that our signals will be delivered + executed before it becomes
unsafe to do so.

Comments?

Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>