Mail Archives: cygwin-developers/1998/06/15/13:06:09
>From: newsham AT lava DOT net (Tim Newsham)
>Date: Mon, 15 Jun 1998 08:49:43 -1000 (HST)
>
>> 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?
>
>scanning over i_* pointers in net.cc:
> accept, recv, recvfrom, connect, gethostbyname, gethostbyaddr
>
> send and sendto might block in some situations (ie. TCP flow control
> window full, and write performed).
>
> rcmd and rexec probably block, I haven't used the winsock versions yet.
>
> (select blocks, but we always call socket select in a seperate thread)
Hmm. That's a lot of calls.
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.
I've got this working in my version of cygwin but I haven't had time to
really run it through its paces.
Does anyone have experience with threads and signals under UNIX? How
does a non-main thread deal with signals? Are non-main threads interrupted
at all? Does signal() effect threads on a per-thread basis?
cgf
- Raw text -