[cairo] Proposal: cairo_save_state/cairo_restore_state

Behdad Esfahbod behdad at cs.toronto.edu
Tue Jan 24 06:23:13 PST 2006

On Tue, 24 Jan 2006, Christian Biesinger wrote:

> Behdad Esfahbod wrote:
> > On Tue, 24 Jan 2006, Christian Biesinger wrote:
> >>Behdad Esfahbod wrote:
> >>>You are right generally, but in this case, since saved states are
> >>>immutable and cairo_t objects are not threadsafe anyway (cannot
> >>>be used from two threads at the same time), I don't think any
> >>>locking is needed, and the semantics I described does the job.
> >>
> >>So can a state only be restored to the context from which it was created?
> >
> > No, definitely not.  That's the beauty of this cairo_state_t
> > approach compared to cairo_copy I believe.
> But, then there is still the threadsafety issue with a copy-on-write
> state, isn't there? The gstate has to be modifiable...

Each cairo_t object is to be used from one thread only.  And
cairo_state_t is immutable.  The thread using cairo_state_t is
supposed to have a reference on it, so it cannot go away behind
its back.  After doing cairo_restore_state, the cairo_t holds a
reference to cairo_state_t and uses it internally.  When an
operation on cairo_t wants to modify the state, it simply copies
the state from cairo_state_t and unrefs the old state.  The new
copied state is only owned by the cairo_t and not subject to
copy-on-write anymore.  The only operations that need to be
threadsafe is the reference/destroy, but seems like they already
are, since they lock the object.  Or at least that's what they
are supposed to be doing IMHO.


"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
	-- Dan Bern, "New American Language"

More information about the cairo mailing list