Re: [HACKERS] [PATCHES] fork/exec patch

> Steve Tibbett wrote:
> > Here's another option - what about using a named pipe? If
> you want to
> > send the process a signal, you open the named pipe, write a single
> byte
> > to it (the signal value) and close the pipe.
> >
> > The server process would launch a thread on startup which
> would create
> > the server side of the pipe and then do an infinite wait on
> the pipe
> > handle. When the wait returns, it would reads a byte and takes that
> > signal action -
> > if the read failed, then it means the main thread has
> closed the pipe
> > handle
> > because it's shutting down, so it would set an event and
> thread would
> > terminate.
>
> I like this idea a lot. I admit though I have to do a little research
> to give a better informed opinion. My feelings wrt messages
> were based
> on a general uneasiness surrounding WaitForSingleObject calls
> via a polling thread, because this will exhibit pseudo-random
> (thus difficult to debug) behavior. Messages allow you to
> avoid this in simple cases by returning to the callback
> occasionally or even checking the message queue in some smart
> places. However, yours and Magnus's objections are valid.
>
> Named pipes are better though but IIRC are NT only, which
> actually I consider to be a Good Thing. They are also more
> unixish in design than either events or messages, which is
> also a Good Thing. Definitely worth a second look.

Named Pipes certainly has a bit more elegance to it, since you have only
one object and not both an event and shared memory. You could even use
an anonymous pipe instead. They work on both 9x and NT (if you should
want it). On NT, it's implemented under the hood using Named Pipes.

Personally, I like the separate thread part because it makes it pick up
the signal real fast, so there is no risk of blocking the signal
*sender*. And if you need to poll somewhere, it has to be better to do
it outside the thread.

You need some decent synchronization around the shared structures used
inside the backend, but since it's just threads in the same process at
that time, a simple CriticalSection should be enough.
But this holds wether you use named pipes or events.

Since the current signal handlers are already used to being called while
in another routine (except when signals are blocked, of course) they
shuold be ready to handle being called in the middle of anywhere.

The main issue with that one is *when* the main thread will be in
alertable state. According to the docs, this will happen on SleepEx,
WaitForSingleObjectEx, WaitForMultipleObjectsEx, SignalObjectAndWait and
MsgWaitForMultipleObjectsEx will put it there. So either you have to
call those explicitly, or the C library or NT itself will have to call
them at some point (for example, when waiting for I/O).

A quick test program that runs in an infinite loop reading a file shows
that the thread does *not* enter alertable state just from that normal
I/O :-( I need to add an explicit SleepEx(0) to make it do that... Which
means that if you both need to execute the signal handler on the main
thread, and don't want to mess around with exceptions, you need to add
polling somewhere in the main thread anyway.

//Magnus