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

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

> > 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.
> 
> 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++ 
Modules.

> > 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: https://github.com/ggeorgiev/gom.
> 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.

Niall

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