On Wed, Feb 4, 2015 at 3:14 AM, Nick Wellnhofer <[email protected]> wrote:
> So a similar scheme could also work for the Python bindings: Call Py_INCREF > instead of Obj_Inc_RefCount when passing a Clownfish object to Python space. > This makes sure that the refcount is increased even for "immortal" objects. That's an interesting idea, though I think it would get ugly in the details. Say that a method returns an "incremented" object: we'd have to Py_INCREF then CFISH_DECREF the return value before passing it to Python. I was really hoping that having Clownfish objects which actually *are* Python objects would allow us to avoid such gymnastics. In any case, I don't think we should be offering method-based overrideable refcount manipulation as a user-level Clownfish feature. This stuff is really hard to get right for the core alone across multiple hosts -- we are nowhere near the point where we can design and document for extensibility. > But to rely on the GIL is a bad proposal anyway. We want Clownfish projects > to be able to release the GIL and then the same thread-safety guarantees > should hold for all host languages. I don't think it's feasible for Clownfish code to release the GIL except for contained operations where we can guarantee no python code will run (e.g. some specific I/O operation). Because there are many opportunities to override Clownfish code with host code, in general the only safe assumption is that for any block of arbitrary Clownfish, some Python code may run. And that means that any such arbitrary block needs to have the GIL. Put another way, a symbiotic object system is not the kind of extension that can release the GIL, because its operation is closely interleaved with the host. The kind of extension that can release the GIL is one which is cleanly separated from the host. (Side note: setting the cached host object under the Perl bindings should use `Atomic_cas_ptr` for immortal object types.) Marvin Humphrey
