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

-- 
Kai Blin
WorldForge developer  http://www.worldforge.org/
Wine developerhttp://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
--
Will code for cotton.


signature.asc
Description: This is a digitally signed message part.

Re: ntdll/server and unix_fd handling

[Alexandre Julliard]

Kai Blin [EMAIL PROTECTED] 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.

-- 
Alexandre Julliard
[EMAIL PROTECTED]