diff options
Diffstat (limited to 'winsup/cygwin/how-signals-work.txt')
| -rw-r--r-- | winsup/cygwin/how-signals-work.txt | 18 |
1 files changed, 16 insertions, 2 deletions
diff --git a/winsup/cygwin/how-signals-work.txt b/winsup/cygwin/how-signals-work.txt index ca1d8ef..710ce39 100644 --- a/winsup/cygwin/how-signals-work.txt +++ b/winsup/cygwin/how-signals-work.txt @@ -1,7 +1,5 @@ Copyright 2001 Red Hat Inc., Christopher Faylor -[This is not yet complete. -cgf] - How do signals work? On process startup, cygwin starts a secondary thread that deals with signals. @@ -111,3 +109,19 @@ 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. 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(). |