From: cgf AT cygnus DOT com (Christopher Faylor) Subject: Re: SIGKILL and blocking 15 Jun 1998 13:06:09 -0700 Message-ID: <199806151923.PAA28485.cygnus.cygwin32.developers@kramden.cygnus.com> To: cgf AT cygnus DOT com, newsham AT lava DOT net Cc: cygwin32-developers AT cygnus DOT com >From: newsham AT lava DOT net (Tim Newsham) >Date: Mon, 15 Jun 1998 08:49:43 -1000 (HST) > >> Finally the light dawns. I never actually looked at the code, and >> assumed that WSACleanup (despite Sergey's explicit reference) was being >> called unconditionally in exit(). I can see now that that is not the >> case. It was only being called for implicit calls, as he repeatedly >> tried to tell me. >> >> So, a winsock call *does* block and the WSACleanup call is essentially >> demonstrating that the winsock code is not 100% thread safe. >> >> In my version of cygwin, all reads occur in a separate thread. That >> means that the main thread is always interruptible. This could be >> extended to blocking socket operations as well. Besides read what other >> operations block? listen? select? > >scanning over i_* pointers in net.cc: > accept, recv, recvfrom, connect, gethostbyname, gethostbyaddr > > send and sendto might block in some situations (ie. TCP flow control > window full, and write performed). > > rcmd and rexec probably block, I haven't used the winsock versions yet. > > (select blocks, but we always call socket select in a seperate thread) Hmm. That's a lot of calls. What I was thinking about doing was having one extra thread per user thread. If the main thread needs to perform an operation that would block, it would either start or continue a separate thread which would handle the blocking operation. The main thread would wait for either the secondary thread to finish or for a signal to occur. If a signal occurs it terminates the secondary thread, cleans up its stack space and returns an EINTR. I've got this working in my version of cygwin but I haven't had time to really run it through its paces. Does anyone have experience with threads and signals under UNIX? How does a non-main thread deal with signals? Are non-main threads interrupted at all? Does signal() effect threads on a per-thread basis? cgf