libs/newlib-cygwin
libs
/
newlib-cygwin
mirror of git://sourceware.org/git/newlib-cygwin.git
4
0
Fork 0
Code Issues Projects Releases Wiki Activity

typo, words.

This commit is contained in:
Christopher Faylor 2001-09-22 01:29:07 +00:00
parent 53df7e2aaf
commit e0197c5ea5
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
winsup/cygwin/how-signals-work.txt
View File

@ -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.