From: cgf AT cygnus DOT com (Christopher Faylor)
Subject: Re: SIGKILL and blocking
15 Jun 1998 12:19:24 -0700
Message-ID: <199806151845.OAA28439.cygnus.cygwin32.developers@kramden.cygnus.com>
To: newsham AT lava DOT net
Cc: cygwin32-developers AT cygnus DOT com

>From: newsham AT lava DOT net (Tim Newsham)
>Date: Mon, 15 Jun 1998 08:17:12 -1000 (HST)
>
>> Actually, if you have protected all of the winsock stuff with
>> block_sig_dispatch()/allow_sig_dispatch(), then the winsock stuff should
>> not be interruptible by *anything*.  These calls block the action of all
>> signals which will cause a dispatch to a signal handler function whether
>> it is 'do_exit' or a user defined function.
>
>block_sig_dispatch blocks the dispatch of the signal (in call_handler)
>but not the previous step which runs in another thread.  It is this
>previous step which calls WSACleanup (exceptions.cc:sig_handle).

Finally the light dawns.  I never actually looked at the code, and
assumed that WSACleanup (despite Sergey's explicit reference) was being
called unconditionally in exit().  I can see now that that is not the
case.  It was only being called for implicit calls, as he repeatedly
tried to tell me.

So, a winsock call *does* block and the WSACleanup call is essentially
demonstrating that the winsock code is not 100% thread safe.

In my version of cygwin, all reads occur in a separate thread.  That
means that the main thread is always interruptible.  This could be
extended to blocking socket operations as well.  Besides read what other
operations block?  listen?  select?

cgf