Izak Burger wrote:
Ok. I had to set +comm to get that info, and modified the code to dump the contents of the COMMTIMEOUTS structure:
trace:comm:SetCommTimeouts ReadIntervalTimeout=4294967295 trace:comm:SetCommTimeouts ReadTotalTimeoutMultiplier=0 trace:comm:SetCommTimeouts ReadTotalTimeoutConstant=0 trace:comm:SetCommTimeouts WriteTotalTimeoutMultiplier=0 trace:comm:SetCommTimeouts WriteTotalTimeoutConstant=5000
MSDN says this means to return immediately with whatever is there.
ReadFile command may also be important - check whether it is being called with an overlapped structure or not.
It is called with an overlapped structure: trace:file:ReadFile 0x88 0x42295ff1 1040 0x4081ace0 0x42295b5f
Hi Izak,
It appears we don't handle this case properly. We only handle ReadIntervalTimeout=MAXDWORD in non-overlapped mode. Can you try the following (untested) patch and see if it fixes the problem?
Mike
Index: server/serial.c =================================================================== RCS file: /home/wine/wine/server/serial.c,v retrieving revision 1.33 diff -u -r1.33 serial.c --- server/serial.c 8 Apr 2004 19:09:04 -0000 1.33 +++ server/serial.c 14 Apr 2004 10:25:45 -0000 @@ -273,6 +273,28 @@ if ( !async ) return;
+ /* + * The following combination of timeout values means we're try to + * read as much data as is available, then return immediately. + */ + if ( (serial->readinterval == MAXDWORD) && + (serial->readmult == 0) && (serial->readconst == 0) ) + { + struct pollfd pfd; + + pfd.fd = get_unix_fd(fd); + pfd.events = POLLIN; + pfd.revents = 0; + poll( &pfd, 1, 0 ); + + if ( !(pfd.revents & POLLIN) ) + { + async_notify( async, STATUS_SUCCESS); + destroy_async( async ); + return; + } + } + async->status = STATUS_PENDING; if(!async->q) {