[Pixman] Valgrind-clean pixman
ranma42 at gmail.com
Sat Aug 28 23:27:32 PDT 2010
On Sat, Aug 28, 2010 at 5:34 PM, Siarhei Siamashka
<siarhei.siamashka at gmail.com> wrote:
> On Saturday 28 August 2010 12:21:52 Andrea Canciani wrote:
>> On Fri, Aug 27, 2010 at 3:58 PM, Siarhei Siamashka wrote:
>> > This code which is setting a global implementation pointer is also not
>> > quite thread safe (though very unlikely to cause any practical problems
>> > other than a bit bigger one time memory leak). I did not look at it in
>> > details, but with your changes for the use of static structures, it may
>> > become a bit worse because two or more concurrent threads now can
>> > potentially try to initialize the same data structures at once when
>> > setting up implementation pointer.
>> Pixman is not thread safe right now (reference counting, in particular).
>> When we fix (probably by using atomics) reference count, it should be very
>> easy to make implementations thread safe, too.
> 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:
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).
We should probably make cairo and pixman thread safety models converge, or at
least be compatible (using pixman/master cairo test suite crashes on
>> 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).
> Sounds nice, but also a bit scary at the same time. Let's hope that pixman is
> not going to become a performance disaster like gstreamer due to adding extra
> thread safety guarantees ;)
The performance hit of thread safety depends heavily on the implementation we
choose (and cairo isn't doing "the right thing" about MT, so some evolution will
probably happen in it, maybe relaxing again the constraints in pixman).
Anyway, what about the "constructive" comments in my previous email (library
Those would solve some thread safety issues and make the code cleaner, too.
More information about the Pixman