[fpc-devel] StdOut capture for FPC RTL

Jonas Maebe jonas.maebe at elis.ugent.be
Thu Nov 25 11:44:09 CET 2010


On 25 Nov 2010, at 11:16, Anton Kavalenka wrote:

> ?? 25.11.2010 12:01, Jonas Maebe ???????(??):
>>
>> On 25 Nov 2010, at 10:52, Anton Kavalenka wrote:
>>
>>> Due to incompatibility of RTL between FPC and Delphi my capturing  
>>> tricks not work.
>>> BTW what the real reason to make these files as threadvar?
>>
>> To prevent multiple threads writing to stdin/stdout/sterr at the  
>> same time from corrupting each other's data (all of these text  
>> files use an internal buffer, even when the output is immediately  
>> flushed afterwards).
> Is not the better way to use something like this:
>
> lock_output();
> try
>  // do something nasty with the buffer
> finally
>   flush(output);
>  unlock_output();
> end;

It's obviously better for Delphi compatibility and for what you want  
to do, but in general I'd say that's simply a different way. It's also  
worse in other ways: performance (not just locking/unlocking, which  
doesn't matter that much since stdio is never that fast, but mainly  
creating the mutexes when the threads are started), backwards  
compatibility with existing FPC code, resources required (mutexes  
require more than threadvars).

I can't imagine that any of that matters much to you though, since it  
does not help you solve your problem. I can't immediately think of a  
way to make this programmatically changeable at run time either.

> There is NO other runtimes on this planet instead FPC RTL which take  
> care of per-thread buffer of output.

That would very much surprise me.

> It is programmers duty to lock/flush buffer in multithreaded  
> environments.

I don't think it's a programmer's duty to define a global lock that  
they manually acquire/release whenever they use writeln() to print  
something to stdout in a multi-threaded program using writeln(). Just  
like the heap manager, ioresult, and the widestring manager are also  
thread-safe by default. In general, I think that all "global" system  
unit functionality is thread safe by default. The only part of the  
standard RTL that isn't, is afaik the crt unit.


Jonas



More information about the fpc-devel mailing list