Re: ext/mt_alloc.h

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <3EC9F8E1.7090500@snon.net> /Stefan & Ola write:
> My and Ola's FSF assignments are now near completion (we have sent back 
> signed assignment papers last week).

Excellent!

> As per the previous discussion here on the list we have prepared a
> new version of the __mt_alloc allocator in a separate file
> ext/mt_alloc.h as well as taken care of a bug (that showed up in
> consumer/producer environment), optimized bin lookup and added some
> rough out-of-memory handling.

OK, I like the tiered-pool design that you used.  I haven't considered
all the details yet but I'd be basically happy as-is (we can
incrementally tweak on mainline once it is in).

> - There are quite a few different #ifndef naming conventions in use - 
> which one should this file use (we chose __GLIBCPP_MT_ALLOC_H)?

No comment (looks OK to me).

> - Currently we include stl_alloc.h in this file since all the other 
> "SGI-style" allocators have defined a set of alloc_traits thingies - is 
> this needed? If not it would suffice with stl_threads.h and functexcept.h?

It is always OK for a library implementation file to do so.

> - Which namespace should this code live in?

I think that it must go in __gnu_cxx .

> Also note that (as mentioned in the original posting 
> http://gcc.gnu.org/ml/libstdc++/2003-03/msg00033.html) this allocator 
> will currently only work on platforms using the pthread_* since there is 
> no __gthread_mutex_init () call in gthr.h (we use pthread_mutex_init () 
> directly!).

OK, this issue must be solved.  It is somewhat complex (only in the
details) but it is possible to copy an idiom used elsewhere in the
library.  If it is completely static usage, then use the idiom in the
original pool allocator.  If it is dynamic usage, then use the idiom I
recently stuck in the rope code.

Regards,
Loren