[Pixman] [PATCH] Do CPU features detection from 'constructor' function when compiled with gcc

Andrea Canciani ranma42 at gmail.com
Tue Oct 5 01:16:49 PDT 2010

On Mon, Oct 4, 2010 at 11:43 PM, Siarhei Siamashka
<siarhei.siamashka at gmail.com> wrote:
> On Monday 04 October 2010 13:19:45 Andrea Canciani wrote:
>> On Sun, Oct 3, 2010 at 10:52 PM, Siarhei Siamashka
>> <siarhei.siamashka at gmail.com> wrote:
>> > From: Siarhei Siamashka <siarhei.siamashka at nokia.com>
>> >
>> > There is attribute 'constructor' supported since gcc 2.7 which allows
>> > to have a constructor function for library initialization. This
>> > eliminates an extra branch for each composite operation and also helps
>> > to avoid complains from race condition detection tools like helgrind.
>> I'm working on threadsafety issues, too, but I don't have a patch ready
>> I pushed
>> http://cgit.freedesktop.org/~ranma42/pixman/commit/?h=wip/simpleops which
>> adds atomic refcounting and (private, automatically called)
>> init/fini functions to pixman.
>> Currently the simpleops library (available at
>> http://cgit.freedesktop.org/~ranma42/simpleops )
>> is not complete, but in a not very distant future it should provide
>> some commonly
>> available features that with different syntax on each os/compiler (in
>> particular, atomics,
>> mutexes, integers of various sizes, constructors/destructors, thread
>> local storage).
>> It should basically be a bunch of headers to hide the
>> platform-specific naming and some
>> autotools magic to detect what is available.
>> I'm working on MacOS X and Ubuntu and compiling with gcc for x86_64,
>> so most of the
>> library is untested, but I expect only minor changes to be needed in
>> most cases, since
>> it is based on code from cairo and/or pixman.
>> I'm also working on a wip/simpleops branch in cairo, so that the same
>> code can be shared
>> between the two libraries (and moving non graphic-related code out of
>> them).
>> Does this look like a viable approach for having these functionalities
>> in pixman?
>> Right now I'm mainly interested in atomic refcounting and valgrind
>> cleanness (threadsafe
>> initialization, destroying pixman_implementation's upon finalization),
>> but cleaning up the
>> TLS stuff would be nice, too.
> Yes, I remember. I just was a bit worried about the absence of recent news
> from
> this front. It's not like you are the only one interested in this stuff ;)
> Should I just drop this simple patch and wait for something better to come
> from you soon?
I'm trying to get some gradient-related changes into master before 0.20,
so I'm afraid that I won't be able to do much work on thread-safety "soon".

The atomic part of simpleops is supposed to work, but untested on most

Even if there is some code for DllMain (win32) and #pragma init (suncc),
constructors/destructors are actually detected only on gcc-like compilers
(i.e. __attribute__).

I'd like to put up a win32 dev environment, but last time I tried I didn't
manage to, so I'm afraid that completion and testing of simpleops will
take more time than you should be willing to wait (before cairo 1.12?).

More information about the Pixman mailing list