On 04/02/2015 21:31, Marvin Humphrey wrote:
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.
Just like we do in the Perl bindings :)
I was really
hoping that having Clownfish objects which actually *are* Python objects would
allow us to avoid such gymnastics.
I was just thinking that our Perl approach might work for Python as well.
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.
+1
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.
I didn't mean to make Clownfish release the GIL automatically but to allow
authors to release it manually. (OTOH, Clownfish could simply reacquire the
GIL when calling back into host space. But it seems that releasing the GIL
only makes sense for longer running operations, so it should be controlled by
the extension writer.)
(Side note: setting the cached host object under the Perl bindings should use
`Atomic_cas_ptr` for immortal object types.)
Good catch.
Nick
