ntdll/server and unix_fd handling

[Kai Blin]

Hi folks,

I'm currently trying to get some integrated Wine/Samba tests working and in 
order to do so, I'm trying to add Samba socket wrapper support to Wine (i.e. 
allow Wine to hook into Samba's fake AF_FILE-based networking for testing).

The socket wrapper code keeps track of the unix_fds of the sockets it's 
wrapping, because it can also _not_ wrap other fds.

Now, I've been trying to connect this in dlls/ws2_32/socket.c:WSASocketW() by 
getting the unix_fd of the SOCKET the create_socket wineserver call returns, 
by calling get_sock_fd().

Now I noticed that every time I call this for the same SOCKET, the unix_fd 
increases by 1, effectively killing the tracking socket_wrapper does.

After some more digging, upstream of the get_sock_fd call, the 
server_get_unix_fd() call always gets the same fd, either from wineserver or 
from the cache. wine_server_handle_to_fd() then seems to call dup() on the 
unix_fd. This seems to be needed because for some reason unix fds are used 
only temporary, so get_sock_fd is always followed by release_sock_fd(), which 
calls a close(). Why is this handled this way?

Cheers,
Kai

[Alexandre Julliard]

Kai Blin  writes:
> After some more digging, upstream of the get_sock_fd call, the 
> server_get_unix_fd() call always gets the same fd, either from wineserver or 
> from the cache. wine_server_handle_to_fd() then seems to call dup() on the 
> unix_fd. This seems to be needed because for some reason unix fds are used 
> only temporary, so get_sock_fd is always followed by release_sock_fd(), which 
> calls a close(). Why is this handled this way?

Because the file descriptor has to remain valid until it is released, so
we have to dup() it as it may get closed from a different thread in the
meantime. We can avoid the dup() in some cases in ntdll, but not in
other dlls since it would let anybody screw up the fd cache.