The new Arthur "two queues" Jackson* implentation of signals

Christopher Faylor
Fri Aug 22 16:05:00 GMT 2003

It has bugged me that Pierre couldn't figure out why I needed two signal
queues ( in
the signal processing stuff so I've been mulling over my new
implementation for a while.  Yesterday, I knew precisely why I needed
two queues.  Today, I'm not so sure.

One thing that the old signal implementation probably suffered from was
WaitForSingleObjects "starvation".  If signals arrived at a fast pace from
the local process then it was possible that signals from other processes
would be ignored for a long time.  My new implementation should rectify
that but this really has nothing to do with the "two queues".

I thought that having signals come in from different directions would
confuse the old code but, in reality, I think (today at 12PM on
2003-08-22) the only thing it did was make things a little less
deterministic.  With the two queues implementation, the chances of a
process sending a signal to itself and then having the signal trigger
on return from kill() are greater than they were a month ago.  Whether
that's a good thing or not is debatable.

This is basically what happens every time I mess with the signal code.
I basically think that I've forgotten something important and that this
is responsible for the odd problem report on cygwin at cygwin.  Then I
make a change and discover that the previous code was probably correct
and that I've been down this road five times previously.

So, the bottom line is that Pierre is probably right, as usual, and that
there is no need for two signal queues, especially given the change in
behavior of sending one signal per semaphore.  However, I do have this
vague feeling that this implementation might be useful for signals/threads
so I'll keep it, at least for now.

Anyway, I just wanted to get my musings into an archive somewhere.  Maybe
next time this happens, I'll be smart enough to go back through mailing
list archives rather than relying on my extremely faulty memory.



More information about the Cygwin-developers mailing list