On 20 December 2013 13:06, David Nadlinger <c...@klickverbot.at> wrote:
> 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
It should be possible if it's druntime handling all module loading (if
you circumvent the module load handlers, don't expect it to work
properly).
eg:
loadModule(mod); // .ctors are ran and modules self register
themselves to 'mod'
mod.sortCtors();
mod.runSharedCtors();
// etc...
