diff options
Diffstat (limited to 'winsup/cygwin/DevNotes')
| -rw-r--r-- | winsup/cygwin/DevNotes | 34 |
1 files changed, 0 insertions, 34 deletions
diff --git a/winsup/cygwin/DevNotes b/winsup/cygwin/DevNotes index 68d8320cd..8e517bf84 100644 --- a/winsup/cygwin/DevNotes +++ b/winsup/cygwin/DevNotes @@ -1,37 +1,3 @@ -2012-08-09 cgf-000014 - -So, apparently I got it somewhat right before wrt signal handling. -Checking on linux, it appears that signals will be sent to a thread -which can accept the signal. So resurrecting and extending the -"find_tls" function is in order. This function will return the tls -of any thread which 1) is waiting for a signal with sigwait*() or -2) has the signal unmasked. - -In redoing this it became obvious that I had the class designation wrong -for the threadlist handling so I moved the manipulation of the global -threadlist into the cygheap where it logically belongs. - -2012-07-21 cgf-000013 - -These changes reflect a revamp of the "wait for signal" functionality -which has existed in Cygwin through several signal massages. - -We now create a signal event only when a thread is waiting for a signal -and arm it only for that thread. The "set_signal_arrived" function is -used to establish the event and set it in a location referencable by -the caller. - -I still do not handle all of the race conditions. What happens when -a signal comes in just after a WF?O succeeds for some other purpose? I -suspect that it will arm the next WF?O call and the subsequent call to -call_signal_handler could cause a function to get an EINTR when possibly -it shouldn't have. - -I haven't yet checked all of the test cases for the URL listed in the -previous entry. - -Baby steps. - 2012-06-12 cgf-000012 These changes are the preliminary for redoing the way threads wait for |