June 07, 2006 Re: A question about moving GC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | 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.
|
June 07, 2006 Re: A question about moving GC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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. |
June 08, 2006 Re: A question about moving GC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Unknown W. Brackets | 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.
|
June 08, 2006 Re: A question about moving GC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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. |
June 08, 2006 Re: A question about moving GC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | 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.
|
June 08, 2006 Re: A question about moving GC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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. |
June 09, 2006 Re: A question about moving GC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Unknown W. Brackets | 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.
|
June 09, 2006 Re: A question about moving GC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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.
|
June 09, 2006 Re: A question about moving GC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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. |
June 09, 2006 Re: A question about moving GC | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | 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. |
Copyright © 1999-2021 by the D Language Foundation