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

[Andrea Canciani]

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
systems.

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?).