From: newsham AT lava DOT net (Tim Newsham) Subject: Re: SIGKILL and blocking 16 Jun 1998 10:48:35 -0700 Message-ID: References: <01BD9913 DOT D7D104F0 AT sos> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: sos AT prospect DOT com DOT ru (Sergey Okhapkin) Cc: cgf AT cygnus DOT com, newsham AT lava DOT net, cygwin32-developers AT cygnus DOT com > Tim Newsham wrote: > > 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. > > > > We have to recall about WSAXXX analogs of berkeley socket calls. All > these calls are asynchronous. Sure, but 'asynchronous' isn't quite what we require. If we start an asynchronous recv, and then a signal comes in, what do we do? Do we kill the thread that started the recv? What if bytes were already copied to the user's buffer? If we start an operation we will need some way to cancel that operation when a signal comes in. Examples: - recv(), signal, sigsetjmp from handler to different code Can sockets still be used? Is the recv'ing socket still valid for use? - recv(), signal, signal handler does a write and recv on the same socket. Does this work properly? - recv, signal, exit. Will the system behave properly when the exit code tries to close the handle that is still in the recv? There is a WSACancelAsyncRequest call, but it is documented to work only for GetHostBy* type calls. So that lets us fix up gethostby*, but what about the remaining blocking socket calls? > Sergey Okhapkin, http://www.lexa.ru/sos Tim N.