This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: replacing new, getting sane allocator/iostreams behavior
- To: Carlo Wood <carlo at alinoe dot com>
- Subject: Re: replacing new, getting sane allocator/iostreams behavior
- From: Levente Farkas <lfarkas at mindmaker dot hu>
- Date: Wed, 04 Jul 2001 10:35:38 +0200
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, libstdc++ at gcc dot gnu dot org
- Organization: Mindmaker Ltd.
- References: <20010630175234.C5098@alinoe.com> <Pine.SOL.3.91.1010703175904.9773A-100000@taarna.cygnus.com> <20010704051906.A25416@alinoe.com>
- Reply-To: lfarkas at mindmaker dot hu
hi,
what's more this version is thread-safe. now just come into my mind that
it can be the reason the old problem when libstdc++ can't be used from
java through JNI. in the original version if two thread try to initialize
ios_base the second one may be faster and return before the real
initialization finished. so IMHO it's a good patch (but I think that
without test or try it).
yours.
Carlo Wood wrote:
>
> On Tue, Jul 03, 2001 at 06:03:51PM -0700, Benjamin Kosnik wrote:
> > Your patch won't work: it disables the sync_with_stdio functionality, for
> > starters.
>
> It does? How? I started off with the source of 3.0 which was:
>
> ios_base::Init::Init()
> {
> if (++_S_ios_base_init == 1)
> {
> // Standard streams default to synced with "C" operations.
> ios_base::Init::_S_synced_with_stdio = true;
> _S_ios_create(ios_base::Init::_S_synced_with_stdio);
> }
> }
>
> and I changed that into:
>
> ios_base::Init::Init()
> {
> if (_S_ios_base_init == 0)
> {
> // Standard streams default to synced with "C" operations.
> ios_base::Init::_S_synced_with_stdio = true;
> _S_ios_create(ios_base::Init::_S_synced_with_stdio);
> }
> ++_S_ios_base_init;
> }
>
> How does that disables the sync_with_stdio functionality?
>
> > Also, with changes to the allocator class and other bits, I'm
> > not quite sure this is possible.
>
> It should be as I looked at this independant of other code (I don't even
> know how that looks like or what it does). The changes I proposed do
> not change the functionality in ANY way - except that it STILL works
> in cases where it now fails (namely when ios_base::Init is created
> from within operator new). When there is NOT an ios_base::Init created
> from within operator new, my changes (should) have no effect at all.
> Therefore it is impossible that it would break something.
>
> If I am wrong then please clarify what I am missing :)
>
> > -benjamin
>
> A sumary of the proposed change is as follows.
> At the moment, the only possiblity is to NOT create a ios_base::Init
> anywhere during a call to operator new (well, at least - that wouldn't
> have any effect). This results in a program flow that can only look like:
>
> ios_base::Init::Init()
> |
> V
> _S_ios_create()
> |
> V
> operator new() [ we can not use std::cout in operator new ]
> |
> return
> |
> V
> _S_ios_create()
> |
> return
> |
> V
> ios_base::Init::Init()
>
> After the change, it is also allowed to have:
>
> ios_base::Init::Init()
> |
> V
> _S_ios_create()
> |
> V
> operator new()
> |
> V
> ios_base::Init::Init()
> |
> V
> _S_ios_create() ^
> | |
> V |
> operator new() |_ actual initialization
> | |
> return |
> | |
> V |
> _S_ios_create() v
> |
> return
> |
> V
> ios_base::Init::Init() (first Init object that is successfully created)
> |
> return
> |
> V
> operator new() [ here we can use std::cout in operator new ]
> |
> return
> |
> V
> _S_ios_create() (returns without (additional) effect)
> |
> return
> |
> V
> ios_base::Init::Init() (second Init object that is successfully created)
>
> --
> Carlo Wood <carlo@alinoe.com>
--
-- Levente
"The only thing worse than not knowing the truth is
ruining the bliss of ignorance."
"Si vis pacem para bellum!"