From: newsham AT lava DOT net (Tim Newsham) Subject: Re: SIGKILL and blocking 15 Jun 1998 15:53:50 -0700 Message-ID: References: <199806151923 DOT PAA28485 AT kramden DOT cygnus DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: cgf AT cygnus DOT com (Christopher Faylor) Cc: cgf AT cygnus DOT com, newsham AT lava DOT net, cygwin32-developers AT cygnus DOT com > 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. Hmm.. so if winsock is not thread safe, this will not work well. - start new thread to recv - perform recv - get signal, kill other thread, run handler, return EINTR ok, so, the other thread may have already consumed some bytes from the stream, or a packet from a connectionless socket. Even worse, what does winsock do when you kill a thread that was making a call? I would put my money on "break" based on other behavior I've seen from winsock. If this is true, then the only way to properly handle this would be to not start the blocking operation in the first place until it is known that the operation won't block. > cgf Tim N.