Nope, now the app just dies with very little trace as to why. Not to worry, I just need to go eat some lunch or something and get my head clear. This conversation has given me a much clearer understanding of what goes on.
Mike McCormack wrote:
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) {