[cairo] UserFontFace vs FtFontFace management (cairomm)

[Murray Cumming]

On Mon, 2008-12-08 at 08:34 -0600, Jonathon Jongsma wrote:
> Anne et Damien Carbonne wrote:
> > Jonathon Jongsma a écrit :
> >> In the current cairomm implementation, the lifetime of the wrapper 
> >> object is managed by the smart pointer that it is created with.  When 
> >> the wrapper object is deleted, the destructor simply calls 
> >> cairo_font_face_destroy() on the wrapped object.

Yes.

Note to self: cairo_*_destroy() functions are actually unreference
functions, only actually destroying if the refcount hits 0.

>   If I were to store 
> >> an owning reference to the wrapper inside of the wrapped C object, the 
> >> wrapper's destructor would never be called, so we'd never _destroy() 
> >> the underlying font face, and it seems that we'd have circular 
> >> reference issues.  Or am I missing something? (quite possible, I admit)

This is a generic problem with 2 things that reference each other, not
just when a wrapper is involved. I guess that cairo has some way of
dealing with that, though I don't know what that is. If someone can
think of an example in cairo then maybe we can find out.

GTK+ deals with this by having a 2-stage destruction process, so an
object can firsk ask referencers to forget their references and then
really destroy itself. 
  
> > In the Ada solution I explained in another mail, the "Ada handle" never 
> > destroys the "Ada object" itself.
> > The "Ada handle" only calls ref and unref.

Using a separate Ada-only refcount?

> > It is cairo that calls destroy on the attached user data when the ref 
> > count is 0.
> > Then, I destroy the Ada create object(s).
> > If I'm correct, there is no cycle here.
> > I think this is applicable to C++: Replace "Ada handle" by "C++ smart 
> > pointer" and "Ada object" by "C++ wrapper".
> 
> 
> Yes, thank you.  This does seem like the proper way to do things, and I spent this weekend 
> redesigning things to work this way.  With those changes, things work just as you would 
> expect them to (e.g. Ian's issue with needing to keep a reference to the UserFontFace 
> object no longer exists).  However, I have not pushed this out, because the changes are 
> quite invasive, and it would mean that we'd essentially be breaking the API/ABI of 
> cairomm, which is obviously a big deal for projects using cairomm.  So I'm still thinking 
> about the proper way to proceed...

I'd like to see that patch, though I hope it's not necessary.

I guess that you are using a separate refcount and a single cairo
reference, much like this attempt to make Glib::RefPtr more generically
useful:
http://bugzilla.gnome.org/show_bug.cgi?id=104332

-- 
murrayc at murrayc.com
www.murrayc.com
www.openismus.com