Boost logo

Boost :

Subject: Re: [boost] a new library Global Object Manager submission interest check
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-06-09 05:32:59

On 8 Jun 2014 at 8:47, George Georgiev wrote:

> > 1. It needs to provide the same facilities as C++ Modules on older compilers
> in a way which falls through to C++ Modules on newer compilers.
> I have tested the implementation on several gcc and msvc compilers - and it
> works. It does not depend on any resent c++ improvements - and outperform
> the static initialization pattern even in its thread unsafe form.

I think you misunderstand me George.

I'm specifically asking for an implementation which emulates the C++
Modules static data system for older compilers, but which disables
itself and passes through to C++ Modules on newer compilers.

That I think would get people here excited.

> > 2. It needs to work correctly as shared libraries are dynamically loaded
> and unloaded.
> This is something that I need to evaluate and add some tests, but I believe
> it will.

I would want to see correct handling of exception throws during
shared library init and deinit. And running out of memory.

> > 3. On top of that base you need thread ordering support such that the DAG
> can coordinate multiple threads during bootstrap and shutdown.
> I am not sure what this means exactly, Could you please elaborate. Usually
> what I do is adding my thread pools and other multi-thread related object
> to the GlobalObjectManager - this way it indirectly helps for the bootstrap
> and shutdown, but this is without any implicit knowledge about their
> multi-thread nature (it is not needed).

Well how I handled it was DAG subgroups, so you could tag parts of
the DAG as only being possible when a placeholder static init item
said it was initialised. Basically I introduced asynchronicity into
the static data init system.

I'll admit now I retrofitted it, and the retrofit wasn't great. But
it persuades me a decent static data init and deinit system ought to
be async capable from the beginning. This is what I mean by thread
ordering support, though of course i/o is another good use case e.g.
initialise a static variable from the contents of a file.

> > 4. It needs to integrate well with debug tools like valgrind e.g. correctly
> get valgrind to account for true resource leaks versus fire and forget
> allocations.
> This is done. It works also well with mcvs _CrtDumpMemoryLeaks()

Oh good! I remember manually running the MSVC CRT final end of
process routines, and then manually exiting the process to get the
MSVCRT leak dump to work right.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at