Clarified GC.addRoot/addRange behavior. #322
Conversation
|
Maybe also update |
|
Yes, this would certainly be a good idea, and I already did that yesterday (as mentioned on IRC). Unfortunately, GitHub was offline when I had the changes ready, so I couldn't update the pull request. Will push the changes later today when I'm at home. |
|
OK, thanks! |
This commit merely swaps the two function definitions. addRoot and addRange are really quite different semantically, there is no point in mixing them.
|
@alexrp: The promised updates. @dsimcha, @complexmath: You might want to have a look at this. |
| * extern(C) void addCallback(void function(void*), void*); | ||
| * | ||
| * // Allocate an object on the GC heap (this would usually be | ||
| * // some application-specific context data. |
|
@alexrp: The »Notes to implementors« section should probably also be updated as it uses |
|
From what I understand, |
|
Yes, it scans the whole block. But should we require conservative scanning? It might make sense for |
|
Right, let's require that the GC scan the pointed-to block if it's managed by the GC, but remove the requirement that it has to be conservative. |
|
The block pointed to by |
|
Argh, no, the docs are clear enough about it. I'm just being silly. |
|
@klickverbot ping; waiting for your changes to the notes to implementors list. |
|
As discussed with Alex on IRC, I will submit the changes to the documentation comment as a separate pull request as further, only tangentially related discussion might be needed on that. |
Clarified GC.addRoot/addRange behavior.
This pull request is the result of the »RFC: Pinning interface for the GC« discussion on digitalmars.D and a resulting rather long IRC discussion between Alex and me.
It updates the
core.memorydocs to reflect my understanding of theGC.addRootresp.addRangefunctions, which as far as I can see matches the actual implementation. Still, it might be a good idea for somebody else to have a second look at the changes.