Re: [kitten] GSS-API and timeouts

[Martin Rex <[e-mail]>]

Nico Williams wrote:
> 
> If you don't want to tackle async init/accept_sec_context now then I
> suggest that you use threads and thread cancellation.

Without looking at the particular environment underlying this discussion,
I've seen problems with termination of blocking/synchronous network
communication.  While doing a shutdown() on a socket across threads
will normally wake blocking threads on Unix system (without invalidating
the socket handle that the thread was blocked on), this does not work
on Microsoft Windows and on some older versions of SunOS.

On Windows, the shutdown will cause network I/O, and if the peer
processes the close event and closes the socket, the blocking thread
will wake up almost instantly.  But if the peer does not process events
on the socket, then it will take 4 minutes 2*MSL (TCP retransmit timeout)
before the thread that is blocking on read will be woken up with a
timeout error on the socket.  While closesocket() does have an immediate
effect, it also invalidates the socket handle, which will require
additional synchronization, so that (a) the socket handle is not used
after closesocket() has been called and closesocket() is only called once.
(The problem is that on a busy multi-threaded server the socket handle
 may get reused by an accept() between the time when a watchdog thread
 forces a closesocket() and the originally blocking thread wakes up.)

-Martin