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