Thread overview | |||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 06, 2013 [D-runtime] druntime should be a shared library/DLL | ||||
---|---|---|---|---|
| ||||
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
|
February 07, 2013 Re: [D-runtime] druntime should be a shared library/DLL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
February 06, 2013 Re: [D-runtime] druntime should be a shared library/DLL | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 |
February 06, 2013 Re: [D-runtime] druntime should be a shared library/DLL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
February 07, 2013 Re: [D-runtime] druntime should be a shared library/DLL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
February 06, 2013 Re: [D-runtime] druntime should be a shared library/DLL | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 |
February 07, 2013 Re: [D-runtime] druntime should be a shared library/DLL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
February 07, 2013 Re: [D-runtime] druntime should be a shared library/DLL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 |
February 08, 2013 Re: [D-runtime] druntime should be a shared library/DLL | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Roberts | 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 |
February 07, 2013 Re: [D-runtime] druntime should be a shared library/DLL | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 |
Copyright © 1999-2021 by the D Language Foundation