On 28 September 2012 18:54, Rob T <r...@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';
