Serial and pread

[Mike McCormack]

Hi Izak,

The wineserver may also change the status of the request to 
STATUS_SUCCESS after a certain timeout is reached.  The problem is most 
likely that the timeout is not being calculated properly.

The code to do that is in server/async.c and server/serial.c.

The timeouts are set by the SetCommTimeouts call.  Try using the +serial 
debug channel to see what timeouts are being set.  The parameters to the 
ReadFile command may also be important - check whether it is being 
called with an overlapped structure or not.

Mike

Izak Burger wrote:

> trace:ntdll:FILE_AsyncReadService 0x42295b4f 0x42295fe1 1
> trace:ntdll:FILE_AsyncReadService read 1 more bytes 9/1040 so far, 
> io_status->u.Status=0x103
> 
> The tracing of io_status->u.Status was added by myself.  I'm not sure if 
> the problem is not perhaps caused by the fact that u.Status is always 
> 0x103 (STATUS_PENDING) and never becomes 0x0 (STATUS_SUCCESS).  Of 
> course, if I change the FD_TYPE to FD_TYPE_SOCKET, the result is always 
> STATUS_SUCCESS, which is probably what the app wants.  Not knowing much 
> about the API or how Windows implements it (haven't programmed in the 
> windows environment for 7 years now) I'm not even sure if this is some 
> kind of a windows quirk exploited by this app.
> 
> If my experience with unix in general is anything to go by, then it 
> would be acceptable to provide a 1040 byte buffer, and read as much data 
> into it as you can (which is almost always less than the 1040 you 
> _could_ theoretically read in one go), then return STATUS_SUCCESS.  Is 
> it the same for windows?  Obviously the above code will return 
> STATUS_PENDING until it has read 1040 bytes, and only then will it 
> return STATUS_SUCCESS.