Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2006-05

TProcess.output.read does not return until process stopped running.

3 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

ik

Hi,

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.

Is that something that suppose to happen ? If so, is there a non blocking way that I can have the given data while the stream still getting data (and make it work like the real idea of streaming) ?

Thanks,

Ido

Reply by email

Jonas Maebe
to ik
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.

Jonas

Reply by email

Bram Kuijvenhoven
to Jonas Maebe
Jonas Maebe wrote 11 lines
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.

Reply by email