Lucifers,
In the Python bindings I've been working on, Clownfish objects *are*
Python objects.
struct cfish_Obj {
PyObject_HEAD
cfish_Class *klass;
};
This presents some challenges with how we manage object allocations at
present.
First, we require that each host binding implement object allocation via
Class_Make_Obj_IMP, but the Clownfish core provides an implementation of
Obj_Destroy_IMP which always calls `free`. This causes problems because
under Python the objects will be allocated using Python's custom
allocator and it won't be valid to `free` them.
As a remedy, I propose that each host binding be required to provide
Obj_Destroy_IMP.
Second, under Python, Clownfish objects use the Python refcount -- which
Python of course accesses directly, rather than going through the
Clownfish Inc_RefCount, Dec_RefCount and Get_RefCount wrappers. This
presents problems for immortal classes like Class, Method, and BoolNum
which override those refcount manipulation methods to do nothing. A
incref from Clownfish-space followed by a decref from Python-space will
cause the refcount to decrease, eventually triggering an immortal
object's destructor while valid references still exist.
To address this issue, I think what we ought to do is take refcount
manipulation outside of method calls, instead manipulating refcounts
directly using macros which wrap either concrete or `static inline`
functions. Immortal types can have their refcount set absurdly high on
object creation, and can have their destructors reset the refcount
rather than invoke deallocation.
Under that system, refcounts will be exceedingly unlikely to fall to 0
under normal circumstances. However, we still have to take care not to
introduce a security vulnerability which happens when a destructor fires
on an immortal object in case someone figures out how to make that
happen artificially -- so I'd like to know if anybody sees problems now,
and I'd like to request that any commits I eventually supply receive
above-average scrutiny.
Marvin Humphrey
