Re: Win32 signal code - first try

> >4) Changes to the current signalling state would simply
> >PulseEvent(someManualEvent)
> Please note that the documentation says: Note This function is
> unreliable and should not be used. It exists mainly for backward
> compatibility.
>
> We might be immune to the problems with it, but we need to check that
> really carefullyi before using it. I try to stay away from functions
> like that, since it can come back and bite you later when something is
> modified :-)

[sheesh] My (aging) MSDN says no such thing, but sure enough, the online
version does
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba
se/pulseevent.asp)

Reading the fine print, it looks ok for our intended use, but it doesn't
inspire much confidence does it :-(

> >[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)]
>
> What would the problem with the critical section be? It should be just
> as safe as a mutex only a lot faster. The limitation it has compared to
> a mutex is that it can only be used between threads in a processes,
> whereas the mutex exists in the global namespace.
> The only thing you really can't do with critical sections, AFAIK, is
> that a thread can only block on one CS at a time. With mutexes, you can
> use WaitForMultipleObjects() on two mutexes and go with whichever became
> available first.

Agree with all that, but the other thing is that you can't use a
CriticalSection in SignalObjectAndWait... which is why I was using this
mutex. In the code I listed, if the CriticalSection was obtained before the
Wait, and Released before the Signal (whilst the mutex is still held) and
the Release (in the other branch), then we'd "probably" be ok (just need to
think it through). Or, you could just use this mutex everywhere, in place of
the CriticalSection, but yes, this will be a *lot* slower, and I'd rather
avoid that.

> Here's another idea altogether for the blocking signals (just
> occured to me, may be seriously flawed, but I figured I should at least
> get it out there):
>
> How about keepnig a bitmask of "queued signals". These are signals that
> were "fired while blocked". Then at the top of the functions that modify
> the signal blocking mask, check if there are any queued executions for
> signals that are currently not blocked (meaning they just became
> unblocked). (And of course, clear the queue of that signal).
> Doing this should remove a lot of the complexity from the signal
> handling threads, since they don't have to stay around until
> the actual execution of the signal.
>
> If a signal is queued twice while blocked, should the handler execute
> twice once the signal is unblocked? If so, the bitmask would have to be
> replaced with an array of counters, but the general idea still remains.
>
> Thoughs?

On the face of it, I can't see why this bitmask/counter idea couldn't be
made to work. Gee, you might even be able to arrange things such that only a
single APC request needs to be queued, and when it executes, just have it
work its way through this array, clearing bits/decrementing counters as it
processes the signals...

(Seems too simple. Must be something wrong with it :-)

Cheers,
Claudio

PS. Can I just say how great it is to be having these discussions? We are
within striking distance of making native Win32 Postgres a reality!

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