-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17125/
-----------------------------------------------------------
Review request for qpid, Gordon Sim and Rafael Schloming.
Bugs: proton-487
https://issues.apache.org/jira/browse/proton-487
Repository: qpid
Description
-------
Work in progress - wanted feedback before I implement tests.
This change introduces "free" methods to the classes which are not currently
being garbage collected - I chose the name as it corresponds to the C API.
I've made a kinda/sorta hacky approach here - wanted some feedback on it:
You'll see that the "free()" call doesn't immediately release the C object (eg,
call pn_link_free(), for example). I've left that call in the object's __del__
method.
Why? Because if the app does this:
my_session.free(); my_link.free()
Which really is backwards - IMHO - we get a seg-fault. The problem is that
having free() immediately free the parent causes the C library to directly free
all the children. This causes the Python child (my_link, in above) to have a
'dangling' reference to the now-freed C link. Since there is no indication
from the C library that the link is gone, the python side really can't clean it
up.
So to get around that I delayed the pn_xxx_free() call to the __del__ method,
and kept "parent references" in each child that prevents the parent from being
__del__ until the child is released.
Thoughts?
Diffs
-----
/proton/trunk/proton-c/bindings/python/proton.py 1554940
/proton/trunk/tests/python/proton_tests/engine.py 1554940
Diff: https://reviews.apache.org/r/17125/diff/
Testing
-------
by hand only.
Thanks,
Kenneth Giusti
