[fpc-devel] TProcess.output.read does not return until process stopped running.

[Bram Kuijvenhoven]

Jonas Maebe wrote:
> On 19 mei 2006, at 15:20, ik wrote:
>> When executing a program using TProcess, it seems that Output.read
>> does not return from the reading, until the execution of the process
>> is over.
> 
> The returning probably happens every 4KB of data or so (and once the 
> program has finished). The reason is that if the communications pipe 
> flushes after every write, you get much less potential parallelism and 
> more system overhead. And that's only the OS-part of the buffering, it's 
> quite possible that the program you execute is also buffering its output 
> and only flushes after every X KB of written data.

I once tried to write a program (in FPC) that interactively communicated with other programs using stdin/stdout. (The client programs were AIs for a game from a programming contest, and the main program put everything together to play an actual game.)

I found that it is important the 'client' programs calls Flush after every Write (or series of Write's yielding one 'message'), and if you don't want your program (the 'host') to wait forever if the client does not write some data as expected (e.g. because of a bug in the client, a client not flushing its output, or a time-out of the AI in my case), you can try to put the stream-reading code in a separate thread. Of course, this means you'll need to do make that code thread-safe. Unfortunately TProcess.Output.Read is blocking...

This whole approach is mainly suitable if the client program flushes it output buffer. If you write the program yourself, have access to its source code, or can specify requirements to people writing it, this requirement can likely be satisfied. (In the case of the game contest mentioned, the contest rules obliged the Flush calls.)

Regards,

Bram

PS The contest is yearly held at http://www.codecup.nl.