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
> 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 http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/