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

[Siarhei Siamashka]

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?

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20101005/a3f9b48e/attachment.pgp>