dynamic library building and loading

[Iain Buclaw]

On 28 September 2012 18:54, Rob T <rob at ucora.com> wrote:
> On Friday, 28 September 2012 at 17:07:16 UTC, Iain Buclaw wrote:
>>
>>
>> Because the [bleeping] runtime does not support running from a shared
>> library.
>
>
> I suppose the answer is very complicated, but why can't the runtime execute
> as a shared lib? Is it a design limitation of the runtime model? This sort
> of problem should have been dealt with from the ground up, not now. What can
> be done to fix it, or is it a major redesign + re-write effort?
>
> -rt

The big implementation issue is that the runtime only passes two data
ranges to the GC to scan. Global data segment and TLS data segment of
the resultant binary/executable.  So any static data stored in shared
libraries aren't scanned / recognised as data we want to keep. So the
use of them may cause sudden unwanted collections.

The way I intend to address it is to have each module handle it's own
gshared/thread data and pass the information to the D runtime during
the module construction stage (.ctor) - there is already something
done this way for _Dmodule_ref - so it may end up being that two new
fields will be tacked onto it; void[] tlsdata, void[] gsharedata;


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';