From:	newsham AT lava DOT net (Tim Newsham)
Subject:	Re: SIGKILL and blocking
15 Jun 1998 15:53:50 -0700 :
Message-ID:	<m0ylhW9-00110MC.cygnus.cygwin32.developers@malasada.lava.net>
References:	<199806151923 DOT PAA28485 AT kramden DOT cygnus DOT com>
Mime-Version:	1.0
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.

- Raw text -