stdio performance in tango, stdlib, and perl
Walter Bright
newshound at digitalmars.com
Sat Mar 24 22:06:26 PDT 2007
Sean Kelly wrote:
>> It does exactly one lock acquire/release for each printf, not for each
>> character written.
> This is still far too granular for most uses.
I disagree. It's been working fine for nearly 20 years now. gcc
implements it the same way, and it's hardly unusable for most uses.
>> 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.
> This is a valid point, but how often is it actually used in practice?
> Libraries generally do not perform error output of their own, and
> applications typically have a coherent approach for output. In my time
> as a programmer, I can't think of a single instance where default
> synchronization to an output device actually mattered. I can certainly
> appreciate this for its predictable behavior, but I don't know how often
> that predictability would actually matter to me.
It apparently comes up often enough in C++ to merit 59,000 hits on
"multithreaded iostreams" and many web pages outlining attempts to solve
the problem.
It is a problem that is solved by every C stdio for multithreaded
environments, although the C standard does not mention the word "thread".
Multithreading threatens to become far more common, not less, as we move
to multicore machines.
If that isn't compelling, ok, but I suggest at a minimum that Tango not
lock into a design that *precludes* adding thread synchronization
without changing user code.
More information about the Digitalmars-d
mailing list