[Cairo] another set of Python bindings
james at daa.com.au
Fri Sep 12 18:31:48 PDT 2003
On 13/09/03 02:43, Bill Spitzak wrote:
>On Thursday 11 September 2003 06:26 pm, James Henstridge wrote:
>>By exposing reference counting operations on cairo_t objects, this
>>particular case would be easy to handle, so that neither the Python code
>>or C code destroy the cairo_t object until both are finished with it.
>Are we talking about cairo "state" objects? Has it been decided that
>reference-counting the states is necessary?
>If not, it seems that the solution is trivial: have 2 python objects, one
>which destroys the state on destruction, and the other that doesn't. Have the
>various calls return the correct type.
This handles the case of making sure Python doesn't step on the toes of
some C code, however it doesn't cover the reverse. If the Python
programmer has one of thise state objects that doesn't own the
underlying C object, it may be pointing at an object that has been freed.
Adding a reference count solves both of these issues in a much more
>If there is reference counts, my recommendation is that there be a "increment
>reference count" call and a "destroy" call. But there should not be any way
>to find out what the reference count is, or decrement it without possibly
>destroying it. This will allow the object to be stored remotely, with only an
>id number transmitted, and allow them to be shared between connections.
Sure. There is no point in having both a "destroy" and a "unref" in the
public API. The object should be destroyed on the last unref.
Email: james at daa.com.au
More information about the cairo