[Bug 38399] Voobly fails to connect to lobby (threaded app close socket in the middle of other thread select call)

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=38399

Sebastian Lackner <sebastian at fds-team.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sebastian at fds-team.de

--- Comment #4 from Sebastian Lackner <sebastian at fds-team.de> ---
(In reply to Bruno Jesus from comment #3)
> Created attachment 51263 [details]
> patch

The patch is not completely correct, you are passing a wrong file descriptor to
the first release_sock_fd() call (should be "fd" instead of "fds[j].fd").
Moreover I think it would be better to add a check to avoid calling
release_sock_fd() with -1 (the rest of the code also checks this).

> 
> The attached patch solves the issue, but I'm looking for cheaper ways. The
> problem is that all descriptors are duplicated (dup call) for reasons I
> don't understand so when we call select with socket A we retrieve handle X
> from the server and do the poll, when we close the socket in a second thread
> it looks like its duplicated copies are still alive because if I try a
> getsockopt on the handle X from inside the select code it still works when I
> really expected it to give an error.

You already wrote the correct reason into the comment of your patch. The idea
is to make sure that handles are never closed while they are still being used
by a different thread. Of course it would also be possible to use refcounting
for that, but I assume dup(...) was used just because its easier. ;)

When I understand the problem correctly, then using a complicated approach with
get_sock_fd() and release_sock_fd() is the only way to do it properly with the
current design. If ws2_32 code gets moved to ntdll at some point in the future
then there might be ways to do it easier.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.