From 8238a68bb202ebf40dfa479a798d2a23ac92b40c Mon Sep 17 00:00:00 2001 From: Christopher Faylor Date: Mon, 17 Sep 2001 18:10:02 +0000 Subject: * syscalls.cc (rmdir): Set cwd to some other location if attempting to rmdir current working directory. --- winsup/cygwin/how-signals-work.txt | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) (limited to 'winsup/cygwin/how-signals-work.txt') diff --git a/winsup/cygwin/how-signals-work.txt b/winsup/cygwin/how-signals-work.txt index ca1d8efd7..710ce39d4 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(). -- cgit v1.2.3