[cairo] Proposal: cairo_save_state/cairo_restore_state

[Behdad Esfahbod]

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.

--behdad
http://behdad.org/

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