diff options
Diffstat (limited to 'winsup/cygwin/DevNotes')
| -rw-r--r-- | winsup/cygwin/DevNotes | 228 |
1 files changed, 0 insertions, 228 deletions
diff --git a/winsup/cygwin/DevNotes b/winsup/cygwin/DevNotes index 68d8320cd..11a01df57 100644 --- a/winsup/cygwin/DevNotes +++ b/winsup/cygwin/DevNotes @@ -1,231 +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 -signals. The problems are shown by the test case mentioned here: - -http://cygwin.com/ml/cygwin/2012-05/msg00434.html - -I've known that the signal handling in threads wasn't quite right for -some time. I lost all of my thread signal tests in the great "rm -r" -debacle of a few years ago and have been less than enthusiastic about -redoing everything (I had PCTS tests and everything). But it really is -time to redo this signal handling to make it more like it is supposed to -be. - -This change should not introduce any new behavior. Things should -continue to behave as before. The major differences are a change in the -arguments to cancelable_wait and cygwait now uses cancelable_wait and, -so, the returns from cygwait now mirror cancelable_wait. - -The next change will consolidate cygwait and cancelable_wait into one -cygwait function. - -2012-06-02 cgf-000011 - -The refcnt handling was tricky to get right but I had convinced myself -that the refcnt's were always incremented/decremented under a lock. -Corinna's 2012-05-23 change to refcnt exposed a potential problem with -dup handling where the fdtab could be updated while not locked. - -That should be fixed by this change but, on closer examination, it seems -like there are many places where it is possible for the refcnt to be -updated while the fdtab is not locked since the default for -cygheap_fdget is to not lock the fdtab (and that should be the default - -you can't have read holding a lock). - -Since refcnt was only ever called with 1 or -1, I broke it up into two -functions but kept the Interlocked* operation. Incrementing a variable -should not be as racy as adding an arbitrary number to it but we have -InterlockedIncrement/InterlockedDecrement for a reason so I kept the -Interlocked operation here. - -In the meantime, I'll be mulling over whether the refcnt operations are -actually safe as they are. Maybe just ensuring that they are atomically -updated is enough since they control the destruction of an fh. If I got -the ordering right with incrementing and decrementing then that should -be adequate. - -2012-06-02 cgf-000010 - -<1.7.16> -- Fix emacs problem which exposed an issue with Cygwin's select() function. - If a signal arrives while select is blocking and the program longjmps - out of the signal handler then threads and memory may be left hanging. - Fixes: http://cygwin.com/ml/cygwin/2012-05/threads.html#00275 -</1.7.16> - -This was try #4 or #5 to get select() signal handling working right. -It's still not there but it should now at least not leak memory or -threads. - -I mucked with the interface between cygwin_select and select_stuff::wait -so that the "new" loop in select_stuff::wait() was essentially moved -into the caller. cygwin_select now uses various enum states to decide -what to do. It builds the select linked list at the beginning of the -loop, allowing wait() to tear everything down and restart. This is -necessary before calling a signal handler because the signal handler may -longjmp away. - -I initially had this all coded up to use a special signal_cleanup -callback which could be called when a longjmp is called in a signal -handler. And cygwin_select() set up and tore down this callback. Once -I got everything compiling it, of course, dawned on me that just because -you call a longjmp in a signal handler it doesn't mean that you are -jumping *out* of the signal handler. So, if the signal handler invokes -the callback and returns it will be very bad for select(). Hence, this -slower, but hopefully more correct implementation. - -(I still wonder if some sort of signal cleanup callback might still -be useful in the future) - -TODO: I need to do an audit of other places where this problem could be -occurring. - -As alluded to above, select's signal handling is still not right. It -still acts as if it could call a signal handler from something other -than the main thread but, AFAICT, from my STC, this doesn't seem to be -the case. It might be worthwhile to extend cygwait to just magically -figure this out and not even bother using w4[0] for scenarios like this. - -2012-05-16 cgf-000009 - -<1.7.16> -- Fix broken console mouse handling. Reported here: - http://cygwin.com/ml/cygwin/2012-05/msg00360.html -</1.7.16> - -I did a cvs annotate on smallprint.cc and see that the code to translate -%characters > 127 to 0x notation was in the 1.1 revision. Then I -checked the smallprint.c predecessor. It was in the 1.1 version of that -program too, which means that this odd change has probably been around -since <= 2000. - -Since __small_sprintf is supposed to emulate sprintf, I got rid of the -special case handling. This may affect fhandler_socket::bind. If so, we -should work around this problem there rather than keeping this strange -hack in __small_printf. - -2012-05-14 cgf-000008 - -<1.7.16> -- Fix hang when zero bytes are written to a pty using - Windows WriteFile or equivalent. Fixes: - http://cygwin.com/ml/cygwin/2012-05/msg00323.html -</1.7.16> - -cgf-000002, as usual, fixed one thing while breaking another. See -Larry's predicament in: http://goo.gl/oGEr2 . - -The problem is that zero byte writes to the pty pipe caused the dread -end-of-the-world-as-we-know-it problem reported on the mailing list -where ReadFile reads zero bytes even though there is still more to read -on the pipe. This is because that change caused a 'record' to be read -and a record can be zero bytes. - -I was never really keen about using a throwaway buffer just to get a -count of the number of characters available to be read in the pty pipe. -On closer reading of the documentation for PeekNamedPipe it seemed like -the sixth argument to PeekNamedPipe should return what I needed without -using a buffer. And, amazingly, it did, except that the problem still -remained - a zero byte message still screwed things up. - -So, we now detect the case where there is zero bytes available as a -message but there are bytes available in the pipe. In that scenario, -return the bytes available in the pipe rather than the message length of -zero. This could conceivably cause problems with pty pipe handling in -this scenario but since the only way this scenario could possibly happen -is when someone is writing zero bytes using WriteFile to a pty pipe, I'm -ok with that. - -2012-05-14 cgf-000007 - -<1.7.16> -- Fix invocation of strace from a cygwin process. Fixes: - http://cygwin.com/ml/cygwin/2012-05/msg00292.html -</1.7.16> - -The change in cgf-000004 introduced a problem for processes which load -cygwin1.dll dynamically. strace.exe is the most prominent example of -this. - -Since the parent handle is now closed for "non-Cygwin" processes, when -strace.exe tried to dynamically load cygwin1.dll, the handle was invalid -and child_info_spawn::handle_spawn couldn't use retrieve information -from the parent. This eventually led to a strace_printf error due to an -attempt to dereference an unavailable cygheap. Probably have to fix -this someday. You shouldn't use the cygheap while attempting to print -an error about the inavailability of said cygheap. - -This was fixed by saving the parent pid in child_info_spawn and calling -OpenProcess for the parent pid and using that handle iff a process is -dynamically loaded. - -2012-05-12 cgf-000006 - -<1.7.16> -- Fix hang when calling pthread_testcancel in a canceled thread. - Fixes some of: http://cygwin.com/ml/cygwin/2012-05/msg00186.html -</1.7.16> - -This should fix the first part of the reported problem in the above -message. The cancel seemed to actually be working but, the fprintf -eventually ended up calling pthread_testcancel. Since we'd gotten here -via a cancel, it tried to recursively call the cancel handler causing a -recursive loop. - -2012-05-12 cgf-000005 - -<1.7.16> -- Fix pipe creation problem which manifested as a problem creating a -fifo. Fixes: http://cygwin.com/ml/cygwin/2012-05/msg00253.html -</1.7.16> - -My change on 2012-04-28 introduced a problem with fifos. The passed -in name was overwritten. This was because I wasn't properly keeping -track of the length of the generated pipe name when there was a -name passed in to fhandler_pipe::create. - -There was also another problem in fhandler_pipe::create. Since fifos -use PIPE_ACCESS_DUPLEX and PIPE_ACCESS_DUPLEX is an or'ing of -PIPE_ACCESS_INBOUND and PIPE_ACCESS_OUTBOUND, using PIPE_ACCESS_OUTBOUND -as a "never-used" option for PIPE_ADD_PID in fhandler.h was wrong. So, -fifo creation attempted to add the pid of a pipe to the name which is -wrong for fifos. - 2012-05-08 cgf-000004 The change for cgf-000003 introduced a new problem: |