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