diff options
| -rw-r--r-- | winsup/cygwin/how-signals-work.txt | 9 |
1 files changed, 5 insertions, 4 deletions
diff --git a/winsup/cygwin/how-signals-work.txt b/winsup/cygwin/how-signals-work.txt index 710ce39d4..7ab85db8b 100644 --- a/winsup/cygwin/how-signals-work.txt +++ b/winsup/cygwin/how-signals-work.txt @@ -111,7 +111,7 @@ 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 +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 @@ -119,9 +119,10 @@ 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. +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(). +called by a high level process like kill(). You would use sig_send +to send a __SIGFLUSH to the signal thread. |