blocking/non-blocking socket question.

[Rein Klazes]

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<juan.lang at gmail.com> 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, that is exactly what I meant.

>>>
>>> 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 the blocking state is
>> transferred across a dup() call.  The file descriptor used in a dll
>> comes from wine_server_handle_to_fd:
>> http://source.winehq.org/source/dlls/ntdll/server.c#L635
>>
>> I confess I don't know whether it is.  But the existence of the
>> do_blocking call strongly implies that it is, doesn't it?
>> --Juan
>>

AFAIK, the only flag that is not preserved across a dup call is the
close-on-exit flag.

>
>It definitely seems that way. Also, if the blocking state is not
>transferred then those fcntl's wouldn't have any effect and hence we
>wouldn't have the bug. But I agree with you that the documentation is
>incredibly vague (what is "state"?) with regards to what the
>implemented behavior should be. It seems it is just a hard link for
>handles. Besides if the state is not transferred, those fcntl's
>wouldn't have any effect as the duped socket is closed when released.

I think it is agreed that the socket code in wine is not entirely
consistent in this respect.

>Rein, I think you can safely make a patch for this bug. In the worst
>case Alexandre will just not take it. ;)

I am used to that, I think I will.

Thank you both for your thoughts. 

Rein.