[Pixman] Making ref counting thread safe

Soeren Sandmann sandmann at cs.au.dk
Sat Jan 8 02:09:11 PST 2011

Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:

> This problem looks bad enough to me, or at least makes me feel uneasy. Changing
> how the caching works could also cause some weird problems in the future unless
> everything is carefully taken into account. Also various tools like helgrind
> will complain a lot and it would be hard to differentiate real problems from
> just some mostly safe ugliness.

I agree this really should be fixed, my main point is that I don't
think it's a huge problem in current practice - in particular,
versions of pixman with these caches have been used with no problems
with cairo 1.8.x, including presumably in some of those applications
that uses images in a read-only way from multiple threads.

> In addition, requiring not to change the properties may be a bit restrictive,
> limiting the usefulness of this model.
> I would suggest to generally forbid using the same pixman_image_t from multiple
> threads, but also add a function for creating pixman_image_t clone, which
> would share the pixel buffer with the original image and track pixel buffer
> lifetime via thread-safe refcounting. So using the same image from another 
> thread would just require creating a clone instead of doing 'pixman_image_ref', 
> all the rest should be exactly the same. 

It might be possible to do both: guarantee that read-only use will
work, but then also add a pixman_image_clone() function for the case
where you want the same pixels with different properties.


More information about the Pixman mailing list