On 13-01-06 09:15 AM, Raimund Steger wrote: > Behdad Esfahbod wrote: >> [...] > >> diff --git a/configure.ac b/configure.ac >> index 5657bb5..fda5650 100644 >> --- a/configure.ac >> +++ b/configure.ac > >> [...] > >> + >> +have_pthread=false >> +if test "$os_win32" = no; then >> + AX_PTHREAD([have_pthread=true]) >> +fi >> +if $have_pthread; then >> + AC_DEFINE(HAVE_PTHREAD, 1, [Have POSIX threads]) >> +fi >> +AM_CONDITIONAL(HAVE_PTHREAD, $have_pthread) > > I was doing some more testing and got coredumps when using FcFontMatch from > multiple threads on Solaris, using GCC as well as Sun Studio (the latter with > atomic operations from atomic.h, see attached -- /experimental/ -- patch -- > which is NO suggestion for the upcoming snapshot release (*) ). Ah, thanks. I'll clean up and commit. > Then I noticed that -mt or -D_REENTRANT had not been passed to 'cc'. Now this > is a Solaris specialty but I think AX_PTHREAD could do all the work: My bad. Will fix. > (*) Solaris atomic operations do not implement a full memory barrier. However, Humm. > I'm not sure whether this is a problem for the way fontconfig uses these > operations. So far I've not been able to attribute any coredumps to _this_ > circumstance. This would need attention from an expert on the subject (which > I'm not). So, did the pthread fixes make the crashes to go away or are you still seeing some? How do you test? Do you have a test program you can contribute back to fontconfig? I'm interested to run that too, since my testing was mostly heavy on the pango side, not fontconfig side. BTW, I'm surprised that the naive implementation didn't work for you. Perhaps explained by the lack of memory barriers. behdad > Raimund > > > -- behdad http://behdad.org/ _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
