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.

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.

"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.

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

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!

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

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

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.

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

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();