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<[email protected]> 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.
