Responding to all your comments:
On Fri, 24 Jul 2009 00:02:01 -0400, you wrote:
>On Thu, Jul 23, 2009 at 10:28 PM, Juan Lang wrote:
>>> I think what Rein means is that the unix socket fd backing the windows
>>> socket handle is always non-blocking - and if he is, he may be
>>> correct:
Yes, tha
On Thu, Jul 23, 2009 at 10:28 PM, Juan Lang wrote:
>> I think what Rein means is that the unix socket fd backing the windows
>> socket handle is always non-blocking - and if he is, he may be
>> correct:
>>
>> http://source.winehq.org/source/server/sock.c#L578 &&
>> http://source.winehq.org/source/s
> I think what Rein means is that the unix socket fd backing the windows
> socket handle is always non-blocking - and if he is, he may be
> correct:
>
> http://source.winehq.org/source/server/sock.c#L578 &&
> http://source.winehq.org/source/server/sock.c#L663
That's true, but it depends on whether
On Thu, Jul 23, 2009 at 1:50 PM, Juan Lang wrote:
>> It is calling recv() on a socket that was previously:
>> 1) set to blocking with a WS_ioctlsock() call with cmd WS_FIONBIO
>> 2) AsyncSelect()'ed that should make the socket non-blocking.
> (snip)
>> while the second does not touch the unix fd. T
> It is calling recv() on a socket that was previously:
> 1) set to blocking with a WS_ioctlsock() call with cmd WS_FIONBIO
> 2) AsyncSelect()'ed that should make the socket non-blocking.
(snip)
> while the second does not touch the unix fd. This leaves the unix file
> descriptor in the blocking st
Hi,
I am looking at bug #12048 http://bugs.winehq.org/show_bug.cgi?id=12048
>From a relay trace it is easy enough to find where the app is getting
dead-locked and why it should not.
It is calling recv() on a socket that was previously:
1) set to blocking with a WS_ioctlsock() call with cmd WS_F
