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

Pierre A. Humblet
Fri Aug 22 18:31:00 GMT 2003

Christopher Faylor wrote:
> 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.


The signal code is very tricky, I am amazed by how many inventive ideas
went in there.

Let's leave the two queues for now, but there are still some features
in my tuneup patch that have not been integrated/discussed (the
test in set_process_mask + avoiding the InterlockedDecrement/Increment
flip flopping). There is also the mask race you discovered.

I also saw a crash last night and just analyzed it:

The stack picture at label 3 when starting the handler,
or just after the call to _set_process_mask@4 when
terminating the handler, is as follows:

ret addr
old ebp        <= ebp
6 registers
errno          <= esp
signal arg
signal handler

So in the recursion elimination code the return address must be 
overwritten at ebp + 4 (my solution) or esp + 36 (your solution)

However your code
        movl    %%esp,%%ebp
        movl    %%eax,36(%%ebp) # Restore return address
produces an ebp different from the one in the sketch above, 
so when you return from the eliminated recursion the stack format 
is wrong and a stack walk crashes. This only happens when 
there are two consecutive recursions.
Just leave ebp alone and change the two lines above to
        movl    %%eax,36(%%esp)  or %%eax,4(%%ebp)

I have two other patches waiting in the wings, until this
is settled and 1.5.3 is released.
- a patch to use the multimedia timer in nanosleep [improving
the resolution to 1 ms, i.e. 1000000 ns :-( ] + bug fixes
- a patch to use the multimedia timer for setitimer/alarm +
bug fixes.

Once that's done we can go back to improving the signal code, 
you will be able to observe directly what I see in heavy load.


More information about the Cygwin-developers mailing list