Re: zero-alloc cache (was Re: [v3] Fix PR libstdc++/10276)

[Jerry Quinn <jlquinn at optonline dot net>]

Benjamin Kosnik writes:
 > 
 > Jerry, I'm just going to assume you read this list.
 > 
 > I think the end goal should be to have something like this work:
 > 
 > #include <ostream>
 >  
 > using namespace std;
 >  
 > class bufferstream : public ostream
 > {
 >   // Types.
 >   typedef char                          char_type;
 >   typedef __locale_cache<char_type>     cache_type;
 >  
 >   // Data.
 >   //cache_type  data;
 >  
 > public:
 >  
 >   bufferstream() : ostream()
 >   {
 >     // Zero alloc.
 >     //this->init(NULL, &data);
 >     this->init(NULL);
 >   }
 > };
 > 
 > However, the problem is more than allocating the __locale_cache, it's
 > what is inside of the __locale_cache.
 > 
 > Fixing that problem is what I thought you were up to.... however, no
 > worries. Now that the gcc-3.3 deadline is looming, let's try to get this
 > wrapped up.

OK, I had originaly thought the goal was to have the standard streams
never call new.  Making the above work is similar, but not identical.
The above will work as is on 3.3 even if the cache has strings in it.

To get to zero alloc, we need to remove any calls to new when a locale
cache is provided, right?  The last patch I sent eliminates the
allocation within register_callback.  Now we have to eliminate the
strings in the cache.

As I mentioned in another email, I'm not familiar with allocators, so
I'm not sure about using a custom allocator to handle string memory in
the cache.  I'm working on a straight pointer solution, but a simple
string wrapper would be nicer.

 > >Umm, ICK!  Actually, there is another leak waiting to happen here,
 > >unrelated to locale cache.  The above leak happens because the
 > >destructors are never called for the static streams.  If someone
 > >happens to store a new'd object in e.g. cout.pword(10) and register a
 > >callback to clean up the storage, this will never get cleaned up.
 > >
 > >This scenario makes me think that we MUST call the standard stream
 > >destructors.
 > 
 > No. See libstdc++/10132 for more info on why this is not possible.

Double ick.  It seems like there's a bit of inconsistency in which
stream ops are supposed to catch exceptions and which ones are not.

The problem I indicated above still exists, though.  Is it a defect in
the standard?  Even if not, perhaps we should add it as a caveat to
the (nonexistent) pword docs?

Jerry