Re: Win32 signal code - first try

>[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 :-(

That's what I thought.

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

Oh, ok, I see the point now. However, if we use the method below, we
should be able to do away with it completely, no?

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

Yes, that was the idea. That would remove a lot of complexity.

>(Seems too simple. Must be something wrong with it :-)
There is certainly a risk of that :) But sometimes the simpler solution
is good enough :-)

Also, from your other mail:

> > >1) Named pipe server creates new thread on receipt of signal
> > I'm assuming you read the signal number somewhere in between here?
> > Before the WriteFile, no?
>
> Yep. The ReadFile section, to pull the signal number, wouldn't change
(ie.
> just how you've got it), so I didn't bother mentioning it. It would
then
> fire a thread to do the signal queuing, and, if the thread gets
created ok,
> WriteFile to release the waiting raise/kill.

But if we are going to create a separate thread, why not do the
ReadFile() in the new thread as well? That will make the listening part
completely immune to any "lockups" from the client side as well (say the
client locking up for some reason *before* sending the signal number.
This should normally not happen, and since it's really a single API call
I have a hard time seing how, but if we're gonig to take the step of
creating a separate thread, let's go all the way).
Following on the MSDN example from
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/bas
e/multithreaded_pipe_server.asp

You cuold get better performance from using I/O completion ports, but
really, we're not going to have *that* many signals :-)

//Magnus