[Pixman] Valgrind-clean pixman

[Soeren Sandmann]

Andrea Canciani <ranma42 at gmail.com> writes:

> > I may be wrong here, but seems like everyone has his own definition of what is
> > considered to be "thread safe". Currently pixman appears to be thread safe as
> > long as same pixman objects (pixman_image_t and the others) are not used from
> > multiple threads simultaneously. This is somewhat similar to the thread safety
> > assumptions of the GNU implementation of a standard C++ template library. I'm
> > adding this link here because they took care of documenting what can be
> > guaranteed when working in a multi-threaded environment, and what can't be:
> > http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html#manual.intro.using.concurrency.thread_safety
> > http://www.sgi.com/tech/stl/thread_safety.html

> I see. Currently cairo makes stronger assumptions about pixman thread safety
> (something like: a pixman_image can be used as source from multiple threads
> as long as no threads is writing to it).

I think allowing an image to be used as a source in multiple threads
and as a destination in only one, is a reasonable guarantee to
give. How far from that are we at the moment?

> >> I'm working on a library of simple inline functions (based on cairo
> >> atomic and mutex implementations) to share some common utility functions
> >> which have different availability on different platforms (right now: atomics,
> >> wideint, mutexes). I hope to make it available soon (after I get autotools
> >> do the right things to make it work).

I'd just as well have these things in pixman directly, unless your new
library can become some sort of 'libfreedesktop' type thing that
contains the various data structures and portability gunk that all
projects end up having.

I wrote some notes at one point on how mutexes and atomics could be
added:

http://cgit.freedesktop.org/~sandmann/pixman/commit/?h=threads&id=99c5d5edfef6275ed38e4ec9881a59f5b4ba9492


Soren