http://bugs.winehq.org/show_bug.cgi?id=17195
Adam Martinson adam.r.martinson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adam.r.martinson@gmail.com
--- Comment #43 from Adam Martinson adam.r.martinson@gmail.com 2011-12-17 17:41:11 CST --- (In reply to comment #38) Don't take what Dmitry says so personally, it may sound like he's trolling but that's not his intention. I'm tempted to agree with you on multithreading, but if that is indeed something that needs to be done Alexandre probably either has to do it himself, or at least be heavily involved in the process.
As I understand it this bug has 2 parts: 1 - FILE_PIPE_MESSAGE_MODE/PIPE_READMODE_MESSAGE: Reads from the pipe get at most 1 message. If the provided buffer is insufficient the remainder of the message is left in the pipe and STATUS_MORE_ENTRIES/ERROR_MORE_DATA results. Using SOCK_SEQPACKET instead of SOCK_STREAM isn't an option, because reads on a SOCK_SEQPACKET socket cause any message remainder to be discarded in the case of an insufficient buffer.
The solutions I've considered for this are either implementing datagrams on top of SOCK_STREAM sockets, as in my patch, or creating a pair of SOCK_SEQPACKET sockets for writing and a pair of SOCK_STREAM sockets for reading, with a server thread that waits for a message on the SOCK_SEQPACKET socket to be available and the SOCK_STREAM socket to be empty, and then relays a single message. The latter is much more of a headache to implement which is why I went with the first option.
2 - FILE_PIPE_COMPLETE_OPERATION/PIPE_NOWAIT: Can you elaborate more on this part as far as current behavior vs correct behavior? I haven't started tackling this part. I'm not convinced that correct behavior here is incompatible with my patch, but I need to understand the problem better.