[IronPython] [python] Re: Announcement: Project to get some CPython C extensions running under IronPython

Curt Hagenlocher curt at hagenlocher.org
Wed Oct 17 23:30:46 CEST 2007


On 10/17/07, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>
> I would be sad if we chose any approach that couldn't work on Mono. :-(


I agree.  Assuming this rules out MC++, I think the next best approach is
(as Paolo suggests) to try to shift as much of the work to C# as possible.

Here's an architecture to think about. Consider the following example for
PySequence_Length:

In C:
typedef int (__stdcall *PFN_iO)(PyObject *);
PFN_iO PFN_PySequence_Length;
void Set_PySequence_Length(PFN_iO callback)
{
    PFN_PySequence_Length = callback;
}
int PySequence_Length(PyObject * object)
{
    return PFN_PySequence_Length(object);
}
In C#:
public delegate int PFN_iO(IntPtr object);

[DllImport("extension.DLL")]
public static extern void Set_PySequence_Length(PFN_iO callback);
public static int PySequence_Length(IntPtr obj_in)
{
    object o = ObjectConverter(obj_in);
    // Do something with o
    return result;
}

public static void SetApiFunctionsAtStartup()
{
    Set_PySequence_Length(PySequence_Length);
}

Ignoring exception-handling for now, the idea is to keep most of the
implementation in C# and to have the C# code register callback functions as
actual implementations for the parts of the Python API that we're going to
duplicate.

This is idea is dependent on a kind of "global registry" of objects with
representations on both sides of the border.  Such a registry will almost
certainly be required in order to translate between the two -- if for no
other reason than to handle reference-counting and/or garbage collection.
Any PyObject being passed across the boundary would then actually be some
kind of index into the registry.

A "PyTuple_New" would call through the delegate into C# where (say) a
List<object> would be created and added to the registry, with its unique
identifer being passed back to the C caller as a "PyObject *".

INCREF and DECREF on the C side would affect a reference count in the
registry. Once the DECREF takes the reference count down to zero, the object
is removed.  At that point, it may very well still be a valid CLR object in
use by other parts of the program -- just not by the C extension.

Objects actually defined in the C extension would be required to use either
PyObject_New or Py_NewReference as part of their initialization in order for
the proper fixups to happen.


What do you think?

--
Curt Hagenlocher
curt at hagenlocher.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071017/eb997b1c/attachment.html>


More information about the Ironpython-users mailing list