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-10 16:19:43

On 9 Jun 2014 at 7:34, George Georgiev wrote:

> > I'm specifically asking for an implementation which emulates the
> > Modules static data system for older compilers, but which disables
> > itself and passes through to C++ Modules on newer compilers.
> This feels a bit of an overkill for what I am suggesting - after all it is
> a single template header file (that does not require precompiling).

I think it could be done using macros. Think __LINE__ and you're
heading the right way to emulating the ordering support in C++

> > I would want to see correct handling of exception throws during
> > shared library init and deinit. And running out of memory.
> I do not see how what I have will affect the exception handling in any way,
> but I will add tests for this too.

Heh. You have some fun coming so.

> > 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.
> >
> What I am suggesting is a very simple system to help for resolving the
> mentioned in the introduction issues. When a global object receives the
> control to initialize itself, it could apply whatever conditions and
> whatever source of input. It looks like the DAG system you are referring
> have a completely different scope of tasks that it was/is solving.

Not really. Data initialisation ordering gets complex very quickly,
because it's semantically identical to booting an OS.

This is why a really good solution would mirror best in practice with
OS booting. A sys V equivalent would work and be simple, but I'm not
sure how useful with modern coding patterns. At a certain
multinational I used to work for, poor static data initialisation
implementation caused multi second process startup times, so this is
a very real problem.

> I have feeling that we are talking for two completely different things. I
> have a very raw version of the GOM here:
> If you would like to keep referencing your DAG system it will be helpful if
> you provide a little bit more information about it. Do you have it
> published somewhere?

Sadly no.

I'm simply preparing you for the kind of stuff which would be asked
during peer review. I doubt I'd be alone in wanting to see async in
there for example, as initialising static data from storage or
network is not uncommon, nor is launching threads and syncing with
them during static init.

Moreover, the monadic continuations framework being prepared for C++
17 is likely to become the right and proper way of specifying ordered
sequences of stuff, and I see no reason it shouldn't do static data
init too. The question would surely be asked "how does this plug into
the monadic continuations framework, and if it doesn't, what good
rationales are there why not?"

Your best rationale right now is because the monadic continuations
framework isn't fleshed out yet, but a year from now that will be
harder to argue.


ned Productions Limited Consulting

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