On Fri, Feb 8, 2013 at 1:48 AM, Brad Roberts <braddr@puremagic.com> wrote:
> Please no.. umbrella issues are useless.  If you need a keyword for searchability, then let's create that.  A bug that is nothing more than a pointer to other bugs just adds work to maintain it.

Keywords must be maintained just the same?!

David
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Fri, 8 Feb 2013, David Nadlinger wrote:

> On Fri, Feb 8, 2013 at 1:48 AM, Brad Roberts <braddr@puremagic.com> wrote:
> > Please no.. umbrella issues are useless.  If you need a keyword for searchability, then let's create that.  A bug that is nothing more than a pointer to other bugs just adds work to maintain it.
> 
> Keywords must be maintained just the same?!
> 
> David

Keywords are fully maintained (beyond the point of creation) on the bugs
that utilize that keyword.  When there's no open bugs in that category,
there's no bugs with the keyword.  Unlike umbrella bugs which would end up
being closed and reopened as bugs are found.  There's no clear 'done' with
umbrella bugs.  See 1001, the stack trace bug, for a classic case of where
they're an anti-pattern.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 2/7/2013 5:22 PM, Brad Roberts wrote:
> Keywords are fully maintained (beyond the point of creation) on the bugs that utilize that keyword. When there's no open bugs in that category, there's no bugs with the keyword. Unlike umbrella bugs which would end up being closed and reopened as bugs are found. There's no clear 'done' with umbrella bugs. See 1001, the stack trace bug, for a classic case of where they're an anti-pattern.

I agree with Brad. Umbrella bugs seem like a great idea, until you use them.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 06.02.2013 23:15, Walter Bright wrote:> This would go a long ways towards solving the dll issue, as then the gc
> and thread instances will automatically be shared.

Time to dig up http://d.puremagic.com/issues/show_bug.cgi?id=4071 again. I had implemented a working shared phobos.dll at that time. I can try to bring it up to date if the approach seems appropriate.

One of the major issues is the missing compiler support to access data in another DLL. The access has to be redirected through the DLL import table, but without annotation in the imported files it's pretty hard to tell whether data is in the same DLL or not. That's why the relocation table is searched and code is patched at startup, but this seems fragile. I just figured it gets worse with TLS data, because you'll need the TLS index of the target DLL; the patch does not deal with this.

IIRC unloading a DLL is not supported in the patch. It is also quite problematic with a GC, because there might always still be objects on the heap that need to call their destructor in the DLL (maybe not collected due to false pointer references).

BTW: it's probably not a good idea to have multiple versions of phobos in different DLLs, because it also contains classes that you might want to share, like files and streams. Also, you'd get multiple instances of objects like moduleinfo and typeinfo, that are often compared by pointer identity.



_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 2/8/13 2:18 AM, Rainer Schuetze wrote:
> On 06.02.2013 23:15, Walter Bright wrote:> This would go a long ways
> towards solving the dll issue, as then the gc
>  > and thread instances will automatically be shared.
>
> Time to dig up http://d.puremagic.com/issues/show_bug.cgi?id=4071 again.
> I had implemented a working shared phobos.dll at that time. I can try to
> bring it up to date if the approach seems appropriate.

Yes please, that would be awesome.

Andrei
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Feb 08, 2013, at 03:53 AM, Walter Bright <walter@digitalmars.com> wrote:

> I agree with Brad. Umbrella bugs seem like a great idea, until you use them.

Creating a bugzilla issue with a title like "Add support for dynamic libraries" would be a valid issue on it's own, regardless if it's a umbrella issue or not.

--
/Jacob Carlborg

On 2/7/2013 11:18 PM, Rainer Schuetze wrote:
> On 06.02.2013 23:15, Walter Bright wrote:> This would go a long ways towards solving the dll issue, as then the gc
> > and thread instances will automatically be shared.
>
> Time to dig up http://d.puremagic.com/issues/show_bug.cgi?id=4071 again. I had implemented a working shared phobos.dll at that time. I can try to bring it up to date if the approach seems appropriate.
>
> One of the major issues is the missing compiler support to access data in another DLL. The access has to be redirected through the DLL import table, but without annotation in the imported files it's pretty hard to tell whether data is in the same DLL or not. That's why the relocation table is searched and code is patched at startup, but this seems fragile. I just figured it gets worse with TLS data, because you'll need the TLS index of the target DLL; the patch does not deal with this.
>
> IIRC unloading a DLL is not supported in the patch. It is also quite problematic with a GC, because there might always still be objects on the heap that need to call their destructor in the DLL (maybe not collected due to false pointer references).
>
> BTW: it's probably not a good idea to have multiple versions of phobos in different DLLs, because it also contains classes that you might want to share, like files and streams. Also, you'd get multiple instances of objects like moduleinfo and typeinfo, that are often compared by pointer identity.

You're going to get those multiple instances regardless of whether Phobos is a dll or not, because there'll be other dlls. The only reasonable solution is to compare the typeinfo strings, too.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 08.02.2013 19:05, Walter Bright wrote:>
> On 2/7/2013 11:18 PM, Rainer Schuetze wrote:
>> BTW: it's probably not a good idea to have multiple versions of phobos
>> in different DLLs, because it also contains classes that you might
>> want to share, like files and streams. Also, you'd get multiple
>> instances of objects like moduleinfo and typeinfo, that are often
>> compared by pointer identity.
>
> You're going to get those multiple instances regardless of whether
> Phobos is a dll or not, because there'll be other dlls. The only
> reasonable solution is to compare the typeinfo strings, too.

My idea was that different packages would go into different DLLs, so every module would only exist in one DLL. But I agree, that's probably not realistic (especially when considering template classes), so we'll have to deal with multiple instances of the same module (and different versions of it) anyway.

But how? What are the issues that can be expected?

The module info array comes to mind: sometimes you need just the DLL local array (e.g. when initializing modules), sometimes you need the whole array over all DLLs (e.g. for the object factory). Should it be possible to distinguish identically named modules in different DLLs?
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 2/8/2013 11:19 PM, Rainer Schuetze wrote:
>  Should it be possible to distinguish identically named modules in different DLLs?


I'm sure attempting that would be a disaster.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 08.02.2013 14:00, Andrei Alexandrescu wrote:
> On 2/8/13 2:18 AM, Rainer Schuetze wrote:
>> On 06.02.2013 23:15, Walter Bright wrote:> This would go a long ways
>> towards solving the dll issue, as then the gc
>>  > and thread instances will automatically be shared.
>>
>> Time to dig up http://d.puremagic.com/issues/show_bug.cgi?id=4071 again.
>> I had implemented a working shared phobos.dll at that time. I can try to
>> bring it up to date if the approach seems appropriate.
>
> Yes please, that would be awesome.
>
> Andrei

I've spent some time on it and have created a Win32 druntime DLL. Stay tuned for some pull requests to come after a few cleanups...

In contrast to the version in the bugzilla report (which linked the DM C runtime library snn.lib into the DLL, but exported all its symbols) I now used the shared C runtime library snd.lib which is the import library for sccrt70.dll). I think that this is the better approach as it allows sharing the C runtime with non-D DLLs. In addition it is easier to translate to other C-runtimes.

Now I realize that this library and the DLL are not found in the free dmc compiler distribution, but only in the commercial distribution. Walter, is there a problem with also adding snd.lib and sccrt70.dll to the DMD release?

_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime