stdio performance in tango, stdlib, and perl

[Walter Bright]

James Dennett wrote:
> Walter Bright wrote:
> That would be true, except that Andrei wrote that
> the guarantee applied to separate processes, and
> that can only be guaranteed if you both use some
> kind of synchronization between the processes *and*
> flush the stream.
> 
> Andrei's claim went beyond mere thread-safety, and
> that was what I responded to.

Ok, but since it is typical to do a flush on newline if isatty(), that 
seems to resolve these inter-process problems.

> There's a place:
> 
> locked(cout) << a << b;
> 
> can be made do the job, using RAII to lock at the
> start of the expression and unlock at the end.

I don't think it is that easy, see: 
http://docs.sun.com/source/819-3690/Multithread.html
and 
http://www.atnf.csiro.au/computing/software/sol2docs/manuals/c++/lib_ref/MT.html


> Right.  I certainly did not intend to imply that any
> serious design would be silly enough to lock for each
> character written (which would be fairly useless
> synchronization in any case).

It's needed if only to avoid corrupting the I/O buffer itself.

>> The problem is such synchronization would be invented and added on by
>> the user, making it impossible to combine disparate libraries that write
>> to stderr, for example, in a multithreading environment.
> Most libraries ought not to do so; coding dependencies
> on globals into libraries is generally poor design.

I think it is unreasonable to tell users they cannot use standard 
cin/cout/cerr in standard ways in their library code.

> The problem is not that users would have to write
> synchronization.  Usually they need to do that. A
> problem would be if some low-level locking inside
> the I/O subsystems gave the impression that the
> user did *not* need to synchronize their own code.
> 
> It's not quite as simple as this.  One (possibly
> killer) argument for building synchronization into
> low-level libraries is to reduce the cost of
> dealing with support issues from bemused users
> who expected not to have to consider thread-safety
> when sharing streams between threads.

I think it is a killer argument. Multithreaded programming is hard 
enough without heaping more burdens on the user.