[Bug libstdc++/12855] Thread safety problems in ios_base::Init

["bkoz at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From bkoz at gcc dot gnu dot org  2003-12-16 17:53 -------
> I have to note thought that ever since std::ios_base::Init::_S_initialized()
> was added (3.3) std::ios_base::Init::Init() didn't call new anymore!
> So, basically there is no need for _S_initialized() as it should always
> return 'true' with the current implementation.

Right. This is what I was trying to express.

> There is the danger (is there?) that operator new will be called from
> elsewhere before the standard streams are initialized - but in that
> case I could indeed create a Init::Init object.

We've moved to zero-alloc initialization: no allocator, no malloc, no new. (Only
placement new). There should be no allocation in initialization anymore
(valgrind tells me this at least). This is by design, and is not likely to
change, ever.

Does this make you feel more at ease?

I'd prefer to not add a new member function or data member to ios_base.

> I'll check our your attachment, thanks.
> The basic problem however was that it is possible for Init() to
> call itself reentrant (by the same thread) and if it does that,
> then the second time it will return WITHOUT that the standard
> streams are initialized; and that is not according to the standard.

I don't see this: the whole point of fixing this bug was to remove this issue.
Init is atomic now.

-benjamin

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12855