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

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

--- Comment #218 from Scott Lindeneau   2008-07-12 11:00:53 ---
(In reply to comment #216)
> You still think it is required even if you think wineserver is an asynchronous?
> POSIX sockets can do non-blocking accept just the same way as non-blocking
> read/writes work; wineserver can emulate asynchronous read/write from
> non-blocking i/o, and it should be able to emulate asynchronous accept (and
> connect too). Existing mechanisms could be used for this. Not sure what you
> meant about flags, though.

Hmm. Maybe I need to read more. What i meant by flags is actually handled by
the completion ports paradigm Here is my program control flow idea.

main thread
> ---AcceptEx----AcceptEx-----AcceptEx------WaitsOnCompletionPorts.  .-data in-->

Wineserver
    AcceptEx-. .-blocks for connect-.   blocks for buffer  .-signals compport-^
                AcceptEx----.   blocks for buffer  .-signals-^
                             AcceptEx----. Blocks                     
.-signals-^

Here acceptex blocks for the socket to connect and blocks to read data off of
the socket until the buffer is full, then it puts the data on the completion
port. AcceptEx does not put data on the completionport until the buffer is
full. Here acceptex is blocking inside of the wineserver, not the main thread
(AcceptEx does not block the main thread until the thread waits on the
completion ports). I was originally thinking that we needed to spawn threads in
the wineserver, but if we already have non-blocking i/o then we can use those
functions to do the blocking for the buffer like so:

Wineserver
    AcceptEx-. .-blocks for connect-. Non-BlockingI/OCall.
                                      Non-BlockingI/OCall----blocks for buffer.
  .-signals completion port-^

Then we just need to be able to queue the Non-Blocking i/o call with the
non-blocking accept. and The AcceptEx psudeo code looks like this:

AcceptEx
 Non-BlockingI/O-Read(Non-BlockingAccept);
 return IO_PENDING;

And we let the non-blocking i/o deal with signaling the completion port.

The reason why I think we need threads is that for the main thread to avoid
being blocked, some other thread(inside the kernal) needs to be blocked in
order to do the i/o waiting.

(sorry if the formating is bad)