http://bugs.winehq.org/show_bug.cgi?id=31438
--- Comment #121 from Alessandro Pignotti alexpigna.dev@gmail.com --- I agree the docs says that TcpSockets should always be buffered, but this does not seem to be true. They definitely are buffered by default, but for HTTP connection the mode is changed in QHttpNetworkConnectionChannel::ensureConnection. You can see that when the connection is not SSL based it will pass the QIODevice::Unbuffered flag to the connectToHost call.
(In reply to Heiko from comment #119)
" // Short circuit for getChar() if (maxSize == 1) { int chint; while ((chint = d->buffer.getChar()) != -1) { ", i.e. buffer usage even in the 1 byte case, so that wine doesn't get battered directly.
That only works if the device is actually buffered, if the buffer is empty getChar will return -1 and the normal code path will be taken. You can see that the buffer is filled later in QIODevice::read, but only if the openMode is not Unbuffered.
Also, when debugging wine's winsock it didn't look like there were 1 byte request from the beginning. Though there were 1-byte requests later on, but that didn't look like that was on the HTTP header anyway and to be application related. Then, something's really screwed. And what makes me also wonder is that somehow there's directly a WS_recv after the WS_send.
I've actually been able to see those 1 byte request in the winsock trace.
And if Qt were to actually read one byte from the WSASocket, other Qt-applications would fail that miserably as well, which they don't.
Well, I agree on this, but maybe Origin downloads maybe small chunks using HTTP. This is just speculation though.
But it seems, that wine somehow does send too many WM_USER messages in response to the armed WSAAsyncSelect events. It should only provide one message until being rearmed afaik.
The messages we all see are not (all) caused by the WSAAsyncSelect notification mechanisms, but by WSARecv message sending a new notification if there is more data available, citing MSDN on the WSAAsyncSelect article. WSARecv is a reeanbling routine.
"For FD_READ, FD_OOB, and FD_ACCEPT events, message posting is level-triggered. This means that if the reenabling routine is called and the relevant condition is still met after the call, a WSAAsyncSelect message is posted to the application. This allows an application to be event-driven and not be concerned with the amount of data that arrives at any one time. Consider the following sequence:"