Deleting wrapped pointer in Cython class

[Paul Londino]

Hi,

I have a pointer to a cpp class wrapped in a Cython class. The cpp class uses RAII, in which it obtains the lock on a file in the filesystem which it releases when the class goes out of scope (or when the pointer is deleted).

Is there a good idiom for deleting this pointer inside the Cython class and at the same time making sure the Cython class can't be used anymore? If I delete or reset the pointer and some other Python object tries to do anything with the class, it's certain to crash. Making it safe would involve putting checks on many functions inside the Cython class and in a bunch of classes that use the Cython class. Python 'del' doesn't seem to force the '__dealloc__' method so the file remains open.

It seems like the file closes correctly when the Python object goes out of scope when I exit the processing function normally, but if I throw an exception (a Python exception) the object persists, even if I don't have an references that I am aware of.

Any assistance with this is appreciated.

-Paul

[Robert Bradshaw]

On Thu, Sep 29, 2016 at 6:47 PM, Paul Londino <lond...@gmail.com> wrote:
> Hi,
>
> I have a pointer to a cpp class wrapped in a Cython class. The cpp class
> uses RAII, in which it obtains the lock on a file in the filesystem which it
> releases when the class goes out of scope (or when the pointer is deleted).
>
> Is there a good idiom for deleting this pointer inside the Cython class and
> at the same time making sure the Cython class can't be used anymore? If I
> delete or reset the pointer and some other Python object tries to do
> anything with the class, it's certain to crash. Making it safe would involve
> putting checks on many functions inside the Cython class and in a bunch of
> classes that use the Cython class. Python 'del' doesn't seem to force the
> '__dealloc__' method so the file remains open.

Leveraging __dealloc__ is the suggested way to do this. del should
work, as long as there aren't references to it elsewhere. (Note that
if you're in an interactive session like ipython, the session itself
may hold onto it as a former result or similar.)

> It seems like the file closes correctly when the Python object goes out of
> scope when I exit the processing function normally, but if I throw an
> exception (a Python exception) the object persists, even if I don't have an
> references that I am aware of.

Perhaps a reference is being persisted as part of the traceback?

Unlike C++, which get deconstructed as soon as they go out of *scope*,
Python objects get deleted as soon as the last reference goes away (or
cyclic gc kicks in). This means you'll never have a handle to a bad
object (safer) but is harder control lifetime.

If you want concrete scopes, another option is to use with statements
with __enter__ and __exit__. The object itself, however, will live on
beyond __exit__ which could mean you'd have to manually guard methods.

- Robert