Mail Archives: cygwin-developers/1998/06/16/10:48:35
> 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.
- Raw text -