View mode: basic / threaded / horizontal-split · Log in · Help
March 08, 2013
Re: Ideas for runtime loading of shared libraries.
On 3/7/2013 6:18 PM, Daniel Murphy wrote:
> "Walter Bright" <newshound2@digitalmars.com> wrote in message
> news:khban1$1lm2$1@digitalmars.com...
>> On 1/2/2012 11:20 AM, Martin Nowak wrote:
>>>    - Libraries might not be unloaded as long as GC collected class
>>> instances
>>> still exist because
>>>      finalization fails otherwise.
>>
>> D doesn't guarantee that finalizers will run on GC allocated objects.
>> Therefore, when unloading a dll:
>>
>> 1. run a gc collection
>> 2. for all objects remaining on the heap
>>         if they have a finalizer and that finalizer points into the dll
>> code
>>              mark them as not having a finalizer
>
> What if their vtbl points into the dll code?
>
> What about delegates or function pointers that point there?

These are problems with *any* dynamic dll code. The answer is to tell the user 
"don't do that". The user should NEVER continue to use objects created by that 
dll or delegates/functionpointers/datapointers that refer to it.

The gc problem, however, is not tractable for the user, so it must be dealt with 
by us, and can be dealt with using the method I described.
March 08, 2013
Re: Ideas for runtime loading of shared libraries.
On 3/7/2013 7:22 PM, Walter Bright wrote:
> On 3/7/2013 6:18 PM, Daniel Murphy wrote:
>> What if their vtbl points into the dll code?
>>
>> What about delegates or function pointers that point there?
>
> These are problems with *any* dynamic dll code. The answer is to tell the user
> "don't do that". The user should NEVER continue to use objects created by that
> dll or delegates/functionpointers/datapointers that refer to it.


In essence, dynamically loading/unloading dlls is like calling malloc/free - it 
cannot be made @safe.
March 08, 2013
Re: Ideas for runtime loading of shared libraries.
"Walter Bright" <newshound2@digitalmars.com> wrote in message 
news:khbloq$284i$1@digitalmars.com...
> On 3/7/2013 7:22 PM, Walter Bright wrote:
>> On 3/7/2013 6:18 PM, Daniel Murphy wrote:
>>> What if their vtbl points into the dll code?
>>>
>>> What about delegates or function pointers that point there?
>>
>> These are problems with *any* dynamic dll code. The answer is to tell the 
>> user
>> "don't do that". The user should NEVER continue to use objects created by 
>> that
>> dll or delegates/functionpointers/datapointers that refer to it.
>
>
> In essence, dynamically loading/unloading dlls is like calling 
> malloc/free - it cannot be made @safe.

I was thinking about implicit unloading.  If this is actually about explicit 
unloading then it makes sense to just be unsafe.
March 08, 2013
Re: Ideas for runtime loading of shared libraries.
On 2013-03-07 22:48, Walter Bright wrote:

> My idea for this is straightforward. A D plugin should use a C
> interface. That means, for example, that a D plugin should NOT pass GC
> allocated references to its caller. Only malloc'd data should pass
> between the plugin and its caller.

If this restriction is needed I think it's very unfortunate. I had 
really hoped to be able to have an OO interface.

Objective-C can load plugins with an OO interface an Objective-C can be 
used with a GC.

-- 
/Jacob Carlborg
March 08, 2013
Re: Ideas for runtime loading of shared libraries.
On 3/7/2013 11:37 PM, Jacob Carlborg wrote:
> If this restriction is needed I think it's very unfortunate. I had really hoped
> to be able to have an OO interface.
>
> Objective-C can load plugins with an OO interface an Objective-C can be used
> with a GC.


Read my other posts in this thread!
March 08, 2013
Re: Ideas for runtime loading of shared libraries.
On 2013-03-08 01:17, Walter Bright wrote:

> D doesn't guarantee that finalizers will run on GC allocated objects.
> Therefore, when unloading a dll:
>
> 1. run a gc collection
> 2. for all objects remaining on the heap
>         if they have a finalizer and that finalizer points into the dll
> code
>              mark them as not having a finalizer

Could we do something like I suggested in another post:

We could create a standard plugin interface in Phobos or druntime, 
something like:

interface Plugin
{
    void initialize ();
    void terminate ();
}

Every plugin should implement this directly or indirectly. "initialize" 
would be called just after the plugin is loaded and "terminate" would be 
called just before unloading.

The plugin would then have a possibility to cleanup after itself.

-- 
/Jacob Carlborg
March 08, 2013
Re: Ideas for runtime loading of shared libraries.
On Friday, March 08, 2013 10:09:33 Jacob Carlborg wrote:
> On 2013-03-08 01:17, Walter Bright wrote:
> > D doesn't guarantee that finalizers will run on GC allocated objects.
> > Therefore, when unloading a dll:
> > 
> > 1. run a gc collection
> > 2. for all objects remaining on the heap
> > 
> >         if they have a finalizer and that finalizer points into the dll
> > 
> > code
> > 
> >              mark them as not having a finalizer
> 
> Could we do something like I suggested in another post:
> 
> We could create a standard plugin interface in Phobos or druntime,
> something like:
> 
> interface Plugin
> {
>      void initialize ();
>      void terminate ();
> }
> 
> Every plugin should implement this directly or indirectly. "initialize"
> would be called just after the plugin is loaded and "terminate" would be
> called just before unloading.
> 
> The plugin would then have a possibility to cleanup after itself.

That's basically what static constructors and destructors do, and it'll be a 
problem if they aren't run when the library is loaded and unloaded.

- Jonathan M Davis
March 08, 2013
Re: Ideas for runtime loading of shared libraries.
On Friday, 8 March 2013 at 03:22:46 UTC, Walter Bright wrote:
> On 3/7/2013 6:18 PM, Daniel Murphy wrote:
>> "Walter Bright" <newshound2@digitalmars.com> wrote in message
>> news:khban1$1lm2$1@digitalmars.com...
>>> On 1/2/2012 11:20 AM, Martin Nowak wrote:
>>>>   - Libraries might not be unloaded as long as GC collected 
>>>> class
>>>> instances
>>>> still exist because
>>>>     finalization fails otherwise.
>>>
>>> D doesn't guarantee that finalizers will run on GC allocated 
>>> objects.
>>> Therefore, when unloading a dll:
>>>
>>> 1. run a gc collection
>>> 2. for all objects remaining on the heap
>>>        if they have a finalizer and that finalizer points 
>>> into the dll
>>> code
>>>             mark them as not having a finalizer
>>
>> What if their vtbl points into the dll code?
>>
>> What about delegates or function pointers that point there?
>
> These are problems with *any* dynamic dll code. The answer is 
> to tell the user "don't do that".

That is completely wrong.
March 08, 2013
Re: Ideas for runtime loading of shared libraries.
On 2013-03-08 10:34, Jonathan M Davis wrote:

> That's basically what static constructors and destructors do, and it'll be a
> problem if they aren't run when the library is loaded and unloaded.

Right, forgot about those.

-- 
/Jacob Carlborg
March 08, 2013
Re: Ideas for runtime loading of shared libraries.
On 03/08/2013 04:22 AM, Walter Bright wrote:
>
> These are problems with *any* dynamic dll code. The answer is to tell
> the user "don't do that". The user should NEVER continue to use objects
> created by that dll or delegates/functionpointers/datapointers that
> refer to it.
>
> The gc problem, however, is not tractable for the user, so it must be
> dealt with by us, and can be dealt with using the method I described.

Right that's the point.
You wouldn't expect the following code to work either.

auto h = loadLibrary("lib");
auto f = loadFunc(h, "func");
closeLibrary(h);
f();
1 2 3 4 5
Top | Discussion index | About this forum | D home