[fpc-devel] StdOut capture for FPC RTL

[Thaddy]

On 25-11-2010 11:44, Jonas Maebe wrote:
>
> On 25 Nov 2010, at 11:16, Anton Kavalenka wrote:
>
> 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.
>
It is about semantics in this case, a "contract" if you want. This 
contract hasn't been defined, except for implementation. It seems that 
is not good enough in the context of what FPC is trying to achieve.

>> 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.
Example needed... In very bended Dutch: go your gang ;-)
>
>> 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
>
In my opinion it is. Furthermore it is a classic example of when and how 
the programmer should not rely on what's given to him beforehand.
If "standard"  is interpreted als globally valid (Unless...). Are we 
wrong to assume this?
But I am also happy sending a bug report through Quality Central to ask 
for FPC compliance.
AFAIK it should be a lock, and a lock written by the programmer.
It should definitely not be a threadvar in my opinion.

Hey, It's Friday!

Regards,

Thaddy