Mail Archives: cygwin-developers/1998/06/15/12:19:24
>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
- Raw text -