Stewart Gordon wrote:
> Walter Bright wrote:
>> Max Samuha wrote:
>>> Thank you for the extensive explanation!
>>> Marking my code with '// !!! Passing a pointer to C.' is what i've
>>> been doing recently:) and it seems the best solution for now until
>>> ares is mature or phobos has pin/unpin, or pointers passed to C are
>>> pinned implicitly.
>>
>> They will be pinned implicitly, no need to call pin/unpin. The only time you're going to have a problem is if the C routine hides the pointer in a malloc'd buffer where the gc won't see it. The gc *will* see pointers on the C stack.
> 
> Would it remain pinned indefinitely, until the C function exits, or until the program explicitly unpins it by some means?

It's pinned because it's on the stack, just like pointers on the stack for your D functions. The gc doesn't know the difference.

Of course, how foolish of me - so there's no worry about the garbage collector killing that in a threaded program either.  Duh.

-[Unknown]

In article <e679ot$7e3$1@digitaldaemon.com>, Walter Bright says...
>Stewart Gordon wrote:
>> Would it remain pinned indefinitely, until the C function exits, or until the program explicitly unpins it by some means?
>
>It's pinned because it's on the stack, just like pointers on the stack for your D functions. The gc doesn't know the difference.

On Wed, 7 Jun 2006 22:11:52 +0000 (UTC), Unknown W. Brackets
<Unknown_member@pathlink.com> wrote:

>Of course, how foolish of me - so there's no worry about the garbage collector killing that in a threaded program either.  Duh.
>
>-[Unknown]
>
>In article <e679ot$7e3$1@digitaldaemon.com>, Walter Bright says...
>>Stewart Gordon wrote:
>>> Would it remain pinned indefinitely, until the C function exits, or until the program explicitly unpins it by some means?
>>
>>It's pinned because it's on the stack, just like pointers on the stack for your D functions. The gc doesn't know the difference.
>

Thanks. It seems I can live with that for now. i can't help saying D is very addictive. imho, the best C-like language i've had a chance to try.

Walter Bright wrote:
> Stewart Gordon wrote:
<snip>
>> Would it remain pinned indefinitely, until the C function exits, or until the program explicitly unpins it by some means?
> 
> It's pinned because it's on the stack, just like pointers on the stack for your D functions. The gc doesn't know the difference.

But what if the foreign code needs to hold onto the pointer for longer than it can remain on the stack?

Stewart.

Stewart Gordon wrote:
> Walter Bright wrote:
>> Stewart Gordon wrote:
> <snip>
>>> Would it remain pinned indefinitely, until the C function exits, or until the program explicitly unpins it by some means?
>>
>> It's pinned because it's on the stack, just like pointers on the stack for your D functions. The gc doesn't know the difference.
> 
> But what if the foreign code needs to hold onto the pointer for longer than it can remain on the stack?

Have the D caller code keep a copy, or use addRoots to tell the gc where the foreign code is holding it.

But the question is for a "moving" GC, which might not consider a local reference to mean "don't move it"...?

-[Unknown]

In article <e6abmn$1iaj$1@digitaldaemon.com>, Walter Bright says...
>
>Stewart Gordon wrote:
>> But what if the foreign code needs to hold onto the pointer for longer than it can remain on the stack?
>
>Have the D caller code keep a copy, or use addRoots to tell the gc where the foreign code is holding it.

Unknown W. Brackets wrote:
> But the question is for a "moving" GC, which might not consider a local
> reference to mean "don't move it"...?

addroots will work with that.

But what if I don't know where the foreign code is holding it?  The C library might not expose this, and then I'm out of luck... unless I can modify it, which I probably can't.

But, this is all theoretical anyway.  I can't even think of a library that keeps a pointer I give it.

-[Unknown]


> Unknown W. Brackets wrote:
>> But the question is for a "moving" GC, which might not consider a local
>> reference to mean "don't move it"...?
> 
> addroots will work with that.

Walter Bright wrote:
> Stewart Gordon wrote:
<snip>
>> But what if the foreign code needs to hold onto the pointer for longer than it can remain on the stack?
> 
> Have the D caller code keep a copy, or use addRoots

What is addRoot_s_?

> to tell the gc where the foreign code is holding it.

How will I know where the foreign code is holding the pointer?  Surely it makes more sense to add the pointer itself as a root.

Moreover, the pinning methods'll need to be documented.  So at the moment, I'm guessing that the following will implicitly pin a GC-allocated block:

- storing a pointer to it in a union
- having a pointer to it on the stack
- adding it as a root

Stewart.

Stewart Gordon wrote:
> Walter Bright wrote:
>> Stewart Gordon wrote:
> <snip>
>>> But what if the foreign code needs to hold onto the pointer for longer than it can remain on the stack?
>>
>> Have the D caller code keep a copy, or use addRoots
> 
> What is addRoot_s_?

http://www.digitalmars.com/d/phobos/std_gc.html


>> to tell the gc where the foreign code is holding it.
> How will I know where the foreign code is holding the pointer?

First of all, the foreign code documentation ought to make some mention of what it does with the pointer - after all, it must even if you malloc'd it so you know when and if you can ever free it. Have the D code caller call addRoot.