On 04/02/2015 04:14, Marvin Humphrey wrote:
However, what I *am* proposing is to install a custom `tp_dealloc`
for the "immortal" classes which resets the refcount and stops there.
If there's a reason that won't work, I haven't discovered it yet.
Sounds good.
(Is our Perl implementation even safe?
Isn't it possible that Perl reuses the cached "inner object" SV if the Perl
refcount drops to zero?)
We should be safe because I don't think that's possible. Perl never gets at
the inner object directly: we give Perl a new RV every time a Clownfish object
needs to be accessed from Perl-space. Creating a new RV causes the inner
object's refcount to rise by 1; when the RV ultimately goes away, it causes
the inner object's refcount to fall by 1, resulting in no net change. And all
these refcount manipulations are thread-safe because the we `SvSHARE` the
inner object for "immortal" Clownfish types.
In the current implementation, intercepting DESTROY should only come into play
during Perl's global destruction.
Thanks for the clarification.
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.
I don't really like the "absurdly high refcount" idea for exactly that
reason. The actual problem with "immortal" objects is that they're shared
across threads and we want to avoid concurrent refcount manipulation. Maybe
this isn't an issue in the Python bindings due to the global interpreter
lock?
Yes. In Python, a C extension must explicitly *release* the GIL in order to
enable concurrency.
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.
Nick
