On 03/02/2015 03:33, Marvin Humphrey wrote:
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.
In the Perl bindings, the work-around is to intercept the destructor. I guess that's not possible in Python. (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?)
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.
Some of this was already proposed when discussing the "immortal" flag. I also have a half-finished branch lying around somewhere.
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.
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?
Nick
