|Subject:||Bug in TIdIOHandler.ReadStream (Indy10)|
|Posted by:||Tim Bates (tim.bat…@cispl.com.au)|
|Date:||Mon, 1 May 2006|
I think I have found a subtle bug in TIdIOHandler.ReadStream (Core/IdIOHandler.pas rev 1.97). I am running this code on a Windows XP Embedded system (touch screen) and using Indy to handle sockets to a client PC that can download updates of the program on the touch screen. The filesystem on the touch screen is on a Flash card, not a hard disk, and it can be fairly slow to write to.
The client (also using Indy10) calls
and then immediately disconnects the TIdTCPClient object. The server calls
IOHandler.ReadStream(Stream, FileSize, False);
but loses the last few bytes of the file, especially on large files.
I think what is happening is that inside TIdIOHandler.ReadStream there is a loop that looks like this:
while Connected and (LWorkCount > 0) do begin
The actual write to the Flash card (via a TFileStream object) must be happening in a separate thread to the read from the socket. There is a race condition between the threads, such that once the client disconnects, the socket code sets Connected := false and this immediately stops this loop, even though (because the file system is slow) not all the bytes have been written to the TFileStream. This race condition would probably be missed on a system with a fast file system, like PCs where I imagine Indy gets most of its usage.
Can someone with the appropriate authority please add this to the Indy bug system? Thanks.