On Friday, 20 December 2013 at 10:54:56 UTC, Iain Buclaw wrote:
As for module discovery, we already generate this in the GDC
backend,
which makes it then the job of runtime to pick-up, sort and run
the
ctors on all modules:
@attribute("constructor")
void __modinit()
{
extern (C) __gshared ModuleReference* _Dmodule_ref;
static private ModuleReference __mymod =
ModuleReference(null, minfo);
__mymod.next = _Dmodule_ref;
_Dmodule_ref = &__mymod;
}
Unless I'm missing something in how module discovery is
supposed to
work, this could be instead amended to:
@attribute("constructor")
void __modinit()
{
extern (C) void __register_module(ModuleInfo *);
__register_module(&minfo);
}
So that any lazily loaded modules would be recorded to an
existing
list and trigger a run-once ctor run.
The _Dmodule_ref approach is virtually the same as we have been
doing in LDC up to now. The problem with regard to runtime
loading of shared libraries is that you need to run certain code
(i.e. the current _d_dso_registry in DMD's/LDC's druntime) when
you know that you have collected all the modules. You can't do
this from a .ctor, because if you also use them for constructing
the module list, you'd need to call the registry function in the
last .ctor to run. And at least if you don't know the order in
which they are written to the executable, you can't know that.
It might be possible to work around this requirement by rewriting
the druntime internals to perform all the collision checking,
etc. one-by-one, but I didn't investigate this in more detail.
David
