how-signals-work.txt

cygwin, 著名的在win32下模拟unix操作系统的东东

Copyright 2001 Red Hat Inc., Christopher Faylor

How do signals work?

On process startup, cygwin starts a secondary thread that deals with signals.
This thread contains a loop which blocks waiting for one of three events:

1) sigcatch_main - a semaphore which, when incremented, indicates that a
   signal may be available for the main thread.  The caller waits for the
   signal to be delivered before returning.

2) sigcatch_nonmain - a semaphore which , when incremented, indicates that
   a signal is available for a non-main thread (currently this is not truly
   implemented).  The caller waits for the signal to be delivered before
   returning.

3) sigcatch_nosync - a semaphore which, when incremented, indicates that
   a signal may be available for the main thread.  The caller does not wait
   for the delivery of the signal before returning.

So, the signal handler blocks waiting for one of these three semaphores.

If one of these is activated, then the the signal handler inspects an
array of integers looking for a non-zero value.  The array corresponds
to the normal UNIX signals + two extra locations for internal usage.
This array is located in the 'sigtodo' array in the procinfo class.

The signal thread uses the InterlockedDecrement function to atomically
inspect elements of the array.  If one one of the elements of the array
is non-zero, then cygwin checks to see if the user has blocked the
signal by inspecting the process signal mask.  If the signal is blocked,
then the current array element is reincremented and the next element is
checked.

If the signal is not blocked, then the function "sig_handle" is called
with the signal number as an argument.  This is a fairly straightforward
function.  It first checks to see if the signal is special in any way.

A special signal is something like SIGKILL or SIGSTOP.  The user has no
control over how those signals affect a UNIX process.  If a SIGKILL is
received then sig_handle calls exit_sig to exit the process.  If SIGSTOP
is called then sig_handle calls the regular signal dispatch function
with a special function argument "sig_handle_tty_stop".  The signal
dispatch function is described below.

An uncaught signal like SIGTERM or SIGHUP will cause the process to exit
with the standard UNIX exit values.  Uncaught signals like SIGUSR1 are
ignored, as on UNIX.

If the signal has an associated signal handler, then the setup_handler
function is eventually called.  It is passed the signal, the address of
the handler, and a standard UNIX sigaction structure.  The meat of
signal processing is in setup_handler.

setup_handler has a "simple" task.  It tries to stop the appropriate
thread and redirect its execution to the signal handler function.
Currently, the "appropriate thread" is only the main thread.  Someday
we'll have to change this to allow cygwin to interrupt other user
threads.

To accomplish its task, setup_handler first inspects the static sigsave
structure.  This structure contains information on any not-yet-handled
signals that may have been set up by a previous call to setup_handler
but not yet dispatched in the main thread.  If the sigsave structure
seems to be "active", then a "pending" flag is set (see below) and the
function returns.  Otherwise processing continues.

After determining that sigsave is available, setup_handler will take one
of two routes, depending on whether the main thread is executing in the
cygwin DLL or is currently in "user" code.  We'll discuss the cygwin DLL
case first.

If sigsave seems to be available, then the frame information for the
main thread is inspected.  This information is set by any cygwin
function that is known to block (such as _read()), usually by calling
'sigframe thisframe (mainthread)' in the cygwin function.  This call
sets up information about the current stack frame of an executing cygwin
process.  Any function which uses 'sigframe thisframe' should be signal
aware.  It should detect when a signal has arrived and return
immediately.  This method is also used throughout the DLL to ensure
accurate frame info for the executing function.  So, you'll see it
sprinkled liberally throughout the DLL, usually at places where
empirical tests have indicated problems finding this address via the
brute force method stack walking method employed in setup_handler.

So, if mainframe is active, that means that we have good information
about the state of the main thread.  Cygwin uses the stack frame info
from this structure to insert a call to the assembly language function
'sigdelayed' in place of the main thread's normal return address.  So,
when a call to (e.g.) _read returns after detecting a signal, it does
not return to its caller.  Rather, it returns to sigdelayed.

The sigdelayed function saves a lot of state on the stack and sets the
signal mask as appropriate for POSIX.  It uses information from the
sigsave structure which has been filled in by interrupt_on_return, as
called by setup_handler.  sigdelayed pushes a "call" to the function
"sigreturn" on the stack.  This will be the return address seen by the
signal handler.  After setting up the return value, modifying the signal
mask, and saving other information on the stack, sigreturn clears the
sigsave structure (so that setup_handler can use it) and jumps to the
signal handler function.  And, so a UNIX signal handler function is
emulated.

The signal handler function operates as normal for UNIX but, upon
return, it does not go directly back to the return address of the
original cygwin function.  Instead it returns to the previously
mentioned 'sigreturn' assembly language function.

sigreturn resets the process mask to its state prior to calling the
signal handler.  It checks to see if any new signals have come in and
calls the handler for them now, ensuring that the order of signal
arrival is more or less maintained.  It checks to see if a cygwin
routine has set a special "restore this errno on returning from a
signal" value and sets errno to this, if so.  Finally, it restores all
of the register values that were in effect when sigdelayed was called.

Ok, you thought I had forgotten about the 'pending' stuff didn't you?
Well, if you can rewind up to the discussion of sig_handle, we'll return
to the situation where sigsave was currently active.  In this case,
setup_handler will set a "pending" flag, will reincrement the appropriate
element of the above signal array, and will return 0 to indicate that
the interrupt did not occur.  Otherwise setup_handler returns 1.

For pending signals, the theory is that the signal handler thread will
be forced to be rerun by having some strategic cygwin function call
sig_send with a __SIGFLUSH "argument" to it.  This causes the signal
handler to rescan the signal array looking for pending signals.

This leads us to the sig_send function.  This is the "client side" part
of the signal manipulation process.  sig_send is the low-level function
called by a high level process like kill().  You would use sig_send
to send a __SIGFLUSH to the signal thread.