pinning revisited

Kirk McDonald kirklin.mcdonald at gmail.com
Mon Jul 24 13:10:38 PDT 2006


Jason O'Brien wrote:
> It's not that any of us need to pin right now, but that the standard
> puts anyone using C interop in a hard place: It's not possible to write
> forward-compatible gc safe code.  We want to, but we can't, and so we
> don't.  Noone is right now, and I'm afraid the more broken code we all
> write the less likely it is a more efficient copying collector will ever
> be worthwhile, and if it does get done all the more code we have to 
> rewrite.
[snip]
> any thoughts?  I really think this is urgent, I don't want to see the D
> community close itself off from a more efficient gc

Yes, if nothing else we need gcpin and gcunpin dummy functions in 
Phobos. Pyd will need this functionality whenever a GC-allocated object 
is wrapped and sent into Python. (It needs to pin the object for the 
duration of its stay in the Python interpreter. As soon as the Python 
wrapper object is collected, it can unpin the object.) Proper nested pin 
support is important: A user might wrap the same D object with multiple 
Python objects, and these might be collected by Python at any time and 
in any order. However, updating Pyd to do this is reasonably simple, as 
I believe all of this only needs to be done in one place. (The same 
place where I keep a reference to all of the D objects currently living 
in Python; that and pinning are two parts of the same operation.)

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki



More information about the Digitalmars-d mailing list