This would go a long ways towards solving the dll issue, as then the gc and thread instances will automatically be shared.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Wed, Feb 6, 2013 at 11:15 PM, Walter Bright <walter@digitalmars.com> wrote:
> This would go a long ways towards solving the dll issue, as then the gc and thread instances will automatically be shared.

Could you elaborate a bit?

As far as I can see, it would not change anything about the fact that you need to be able to handle GC ranges from multiple images (static data, TLS) that are added/removed dynamically.

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

On 2/6/2013 3:23 PM, David Nadlinger wrote:
> On Wed, Feb 6, 2013 at 11:15 PM, Walter Bright <walter@digitalmars.com> wrote:
>> This would go a long ways towards solving the dll issue, as then the gc and
>> thread instances will automatically be shared.
> Could you elaborate a bit?
>
> As far as I can see, it would not change anything about the fact that
> you need to be able to handle GC ranges from multiple images (static
> data, TLS) that are added/removed dynamically.
>

The thread code has some global variables where it keeps track of all threads. With the static library approach, there are two sets of these variables, and two sets of code to deal with them. They will conflict with each other, and any attempt to make DLLs will have to have some mechanism to decide which one wins. With druntime itself as a DLL, this is not an issue.

The same problem with the gc.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Wed, 6 Feb 2013, Walter Bright wrote:

> On 2/6/2013 3:23 PM, David Nadlinger wrote:
> > On Wed, Feb 6, 2013 at 11:15 PM, Walter Bright <walter@digitalmars.com> wrote:
> > > This would go a long ways towards solving the dll issue, as then the gc
> > > and
> > > thread instances will automatically be shared.
> > Could you elaborate a bit?
> > 
> > As far as I can see, it would not change anything about the fact that you need to be able to handle GC ranges from multiple images (static data, TLS) that are added/removed dynamically.
> > 
> 
> The thread code has some global variables where it keeps track of all threads. With the static library approach, there are two sets of these variables, and two sets of code to deal with them. They will conflict with each other, and any attempt to make DLLs will have to have some mechanism to decide which one wins. With druntime itself as a DLL, this is not an issue.
> 
> The same problem with the gc.

I'm all for 'forcing the issue', but only if someone is stepping up to drive and own making it really work.  There's been a couple of really great volunteers pushing things forward slowly but surely.  If this suggestion is a conscious statement of "I'm (Walter) willing to help shepherd through the remaining issues and be an active participant in making it work well" then I'm highly in favor of it.  But if it's anything short of that then it's an empty suggestion, imho.  We can't just "go a long way" with things like this.  It's the accumulation of partly done work that drives people so nuts about D.

My 2 cents,
Brad

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

On Thu, Feb 7, 2013 at 1:10 AM, Walter Bright <walter@digitalmars.com> wrote:
> The thread code has some global variables where it keeps track of all threads. With the static library approach, there are two sets of these variables, and two sets of code to deal with them. They will conflict with each other, and any attempt to make DLLs will have to have some mechanism to decide which one wins. With druntime itself as a DLL, this is not an issue.
>
> The same problem with the gc.

Yes, of course you need to have the runtime as a shared library in order to write a sane implementation. Martin's pull request does change the make files accordingly.

But the situation is a *bit* more complex than that. For example, currently the GC root ranges for static and TLS data are just determined once at program startup by taking the address of the respective marker symbols. This clearly can't work in the presence of multiple images that can also be loaded and unloaded during execution, and having a shared druntime doesn't magically change that.

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

On 2/6/2013 4:56 PM, David Nadlinger wrote:
> But the situation is a *bit* more complex than that. For example, currently the GC root ranges for static and TLS data are just determined once at program startup by taking the address of the respective marker symbols. This clearly can't work in the presence of multiple images that can also be loaded and unloaded during execution, and having a shared druntime doesn't magically change that.


I know about that (heck, I wrote a lot of that code). Making druntime a shared lib does not magically solve that particular problem. But it *does* solve the problem of two instances of the gc fighting each other.

Another issue that needs solving is scanning the exception handling tables for shared libraries as they are loaded and unloaded. Oh, and the static construction/destruction.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 6 feb 2013, at 23:15, Walter Bright <walter@digitalmars.com> wrote:

> This would go a long ways towards solving the dll issue, as then the gc and thread instances will automatically be shared.


Yes, please. I've been arguing for supporting shared libraries for a while. I'm willing to help out, especially the Mac OS X specific parts.

Perhaps we should create an issue which keeps track of what more specifically must be done to support shared libraries.

-- 
/Jacob Carlborg

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

On Thu, 7 Feb 2013, Jacob Carlborg wrote:

> On 6 feb 2013, at 23:15, Walter Bright <walter@digitalmars.com> wrote:
> 
> > This would go a long ways towards solving the dll issue, as then the gc and thread instances will automatically be shared.
> 
> 
> Yes, please. I've been arguing for supporting shared libraries for a while. I'm willing to help out, especially the Mac OS X specific parts.
> 
> Perhaps we should create an issue which keeps track of what more specifically must be done to support shared libraries.
> 
> -- 
> /Jacob Carlborg

No, not one.  Create one per problem.  That's far more manageable (ie,
issues can actually be closed).  But, yes, use the tools to track the
issues, it's why we have them. :)
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Fri, Feb 8, 2013 at 12:22 AM, Brad Roberts <braddr@puremagic.com> wrote:
> On Thu, 7 Feb 2013, Jacob Carlborg wrote:
> [...]
>> Perhaps we should create an issue which keeps track of what more specifically must be done to support shared libraries.
>
> No, not one.  Create one per problem.

... and then mark them as blocking a single umbrella issue.

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 12:22 AM, Brad Roberts <braddr@puremagic.com> wrote:
> > On Thu, 7 Feb 2013, Jacob Carlborg wrote:
> > [...]
> >> Perhaps we should create an issue which keeps track of what more specifically must be done to support shared libraries.
> >
> > No, not one.  Create one per problem.
> 
> ... and then mark them as blocking a single umbrella issue.
> 
> David

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.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime