RE: libstdc++/10193: Regression: iostreams no longer threadsafe

[Pétur Runólfsson <peturr02 at ru dot is>]

I apologise for taking so long to reply to this.

>     In terms of there being a change in behavior, your 
> observation is correct.  However, we consider the new 
> behavior to be in line with our published guidelines on 
> application requirements to obtain correct thread safety.  In 
> sum, all library objects  which are visibly shared across 
> threads need to have application-level locking to obtain 
> thread safety.
>     After reading the discussion on this topic in the library 
> documentation,
>     please report your agreement or disagreement with this change.

There seem to be two main points in the documentation that apply
here:

1) That the application can easily provide locking, so the library
   doesn't need to do so.

2) That adequate locking can't be provided by the library.

I agree with point 1), except for the global objects cout, cerr
etc. It seems implied that library code that's intended to be
thread-safe can't touch these objects and that multi-threaded
programs can't use third-party libraries that may use these
objects.

Point 2) seems implied by the statement
>  you might not think of an I/O stream as a container, but
>  the points made there also hold here.
I don't agree with this: The most basic reason
containers can't be made thread-safe is that they return
references to internal data structures, but I/O operations
return by value. I also disagree with this because thread-safe
iostreams implementations exist (most notably gcc-2.95); using
such an implementation without external locking may be somewhat
tricky, but is in many cases possible.

Petur