[Bug 9787] Warcraft3 Battle.net Doesn't work (Needs AcceptEx)

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=9787





--- Comment #220 from Andrey Turkin <andrey.turkin at gmail.com>  2008-07-15 13:25:30 ---
(In reply to comment #219)
> Regarding the missing connections (or the apparently missed connections), they
> could originate from the lack of implementing data_len correctly or status
> messages getting lost somewhere. For instance, as the patch is written:
> 
> +static NTSTATUS WS2_async_accept(void* user, IO_STATUS_BLOCK* iosb, NTSTATUS
> status)
> ... Edited for relevance
> +    case STATUS_ALERTED:
> +        SERVER_START_REQ( accept_socket )
> +        {
> ................
> +            status = wine_server_call( req );
> +        }
> +        SERVER_END_REQ;
> +
> +        if (!status)
> +        {
> +            status = AcceptEx_recv( ......);
> +        }
> 
> The accept_socket function will only return NULL or 0 or FALSE when the
> accept_socket call fails, thus the AcceptEx_recv function is being called when
> there is accept function fails, which I believe is the incorrect behavior. I
You are mixing up accept_socket function and accept_socket handler.
accept_socket return either NULL in case of error, or object in case of
success. accept_socket handler, though, returns NTSTATUS just like all other
handlers, so !status is true when and only when status is STATUS_SUCCESSFUL
(which is equal to 0). AcceptEx_recv gets called only after successful accept.
> believe it should re-queue itself in the async queue due to the multi-threaded
> nature of the system. (I also believe the accept should be made atomic with
> mutex's but I don't know if thats implemented elsewhere or not in the
> async_queue functions or not).
and the socket gets queued (at this point it should not have been in queue
already, so not re-queued but queued) if accept_socket fails with EWOULDBLOCK.
Worry no about mutexes and synchronization etc - wineserver _is not_
multithreaded, there can be no two simultaneous requests. wineserver
essentially runs in big loop, reading and executing one request at the time.
> It is also possible that the acceptex_recv should be done asynchronously
> itself, and the windows error stack should not be updated until after the data
> is received.
Totally agree, it should be! Unfortunately, currently async code in wineserver
does not allow restarting request after server->client call, or attaching same
request to another fd, which is necessary to correctly implement AcceptEx (and
also do the same for TransmitFile/TransmitPackets and maybe some other advanced
i/o functions)


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.