Re: [boost] a new library Global Object Manager submission interest check

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/