On 09/22/2010 01:18 AM, Gary V. Vaughan wrote:
> Actually this patch seems to make no discernable difference to the behaviour
> of the build in both cases above.
That's odd, because adding "gl_use_threads_default=no" should cause
"configure" to default to --disable-threads behavior.
What is the
On 09/22/2010 12:46 AM, Gary V. Vaughan wrote:
> After a `git reset --hard master && git clean -d -x -f', and
> applying the patch again freshly, it works perfectly well, and without
> the problems of undefined symbols like the previous patch.
OK, thanks, I pushed that patch, here:
http://git.sav
Hi Paul,
On 22 Sep 2010, at 02:03, Paul Eggert wrote:
> Gary, could you please also try the following patch to coreutils,
> either by itself,
gcc -std=gnu99 -I. -I../../src -I../lib -I../../lib-g -O2 -MT sort.o -MD
-MP -MF .deps/sort.Tpo -c -o sort.o ../../src/sort.c
../../src/sort.c:243:
Hi Paul,
Thanks for the swift response.
On 22 Sep 2010, at 12:33, Paul Eggert wrote:
> On 09/21/2010 10:11 PM, Gary V. Vaughan wrote:
>
>> But the patch causes a bizarre and apparently unrelated compilation
>> error:
>>
>> ; make V=1
>> gcc -std=gnu99 -I. -I../lib -g -O2 -MT sigprocmas
On 09/21/2010 10:11 PM, Gary V. Vaughan wrote:
> But the patch causes a bizarre and apparently unrelated compilation
> error:
>
> ; make V=1
> gcc -std=gnu99 -I. -I../lib -g -O2 -MT sigprocmask.o -MD -MP -MF
> .deps/sigprocmask.Tpo -c -o sigprocmask.o ../lib/sigprocmask.c
> ../lib/si
Hi Paul,
On 21 Sep 2010, at 14:49, Paul Eggert wrote:
> Could you try the following patch instead? It tries an idea discussed
> earlier today, namely, fall back on mutexes if spinlocks aren't there.
> You'll need not only to update lib/pthread.in.h and m4/pthread.m4, but
> also to get that code f
Gary, could you please also try the following patch to coreutils,
either by itself, or along with the updated gnulib patch? Thanks.
configure: default gnulib to not using threads
* configure.ac: Set gl_use_threads_default=no so that gnulib is
configured without threading. The only coreutils app
On 09/21/10 10:40, Bruno Haible wrote:
> You can do so by inserting
> gl_use_threads_default=no
> in your configure.ac, before the invocations of gl_INIT_EARLY and gl_INIT.
Thanks, I didn't know that. I tried it, and found one minor glitch.
"configure" said "checking for multithread API to use.
Paul Eggert wrote:
> the problem is that coreutils does not need and does not want
> that multithreaded access, and yet it has to build the multithreaded
> support anyway. ...
> It'd be better if applications could say "I don't need gnulib to be
> multithread-safe, and please don't bother with thr
On 09/21/10 03:43, Bruno Haible wrote:
> The modules 'lock', 'tls',
> etc. are needed by the modules 'strsignal', 'fstrcmp', and 'localename'.
> Basically, every piece of code that wants to provide multithreaded
> access to a global variable (may it be a registry or cache or anything)
> needs locki
Hi Paul,
> The problem is that the gnulib i18n code includes pthread.h for its
> own purposes
I wouldn't call it "the gnulib i18n code". The modules 'lock', 'tls',
etc. are needed by the modules 'strsignal', 'fstrcmp', and 'localename'.
Basically, every piece of code that wants to provide multit
On 09/20/2010 05:43 PM, Gary V. Vaughan wrote:
> Hmm... looking at gnulib/pthread.h, am I right in assuming that
> threads are now effectively disabled by gnulib on the mac in favour
> of a selection of stub functions? In which case, I suppose those
> warnings indicate that glthread/lock.c may at
Hi Paul,
On 21 Sep 2010, at 00:30, Paul Eggert wrote:
> On 09/20/10 00:14, Gary V. Vaughan wrote:
>
>> lib/pthread.h does have a typedef for pthread_spinlock_t, but it is
>> predicated on not having HAVE_PTHREAD_T defined (which I do):
>
> Ah, OK. Could you try the following patch instead?
Th
On 09/20/10 14:38, Chen Guo wrote:
> How difficult would it be to implement a basic spinlock in gnulib, though?
Portably? I'd think it'd be quite a pain, as it would require
figuring out this platform's atomic instructions, dealing with memory
barriers, and the like.
> I suppose a performance h
Hi all,
First regarding mutexes on Macs, I suppose a performance hit with mutexes beats
no performance at all with missing spinlocks. And regarding "take more work," I
believe spinlocks and mutexes were basically interchangeable in terms
of functionality
in our sort algorithm; the work probably wi
On 09/20/10 02:33, Pádraig Brady wrote:
> On a related note, I've been meaning to check
> if mutexes in coreutils/sort are more stable
> and/or fair to the system than spinlocks.
They ought to be fairer, though I'd expect there to be a significant
performance price in some cases. I'm not sure wha
On 09/20/10 02:24, Bruno Haible wrote:
> why not use mutexes instead of spinlocks on this platform?
That might be a good thing to try, though it'd take more work.
Chen, what do you think? Here's the email that started this discussion:
http://lists.gnu.org/archive/html/bug-coreutils/2010-09/msg00
On 09/20/10 00:14, Gary V. Vaughan wrote:
> lib/pthread.h does have a typedef for pthread_spinlock_t, but it is
> predicated on not having HAVE_PTHREAD_T defined (which I do):
Ah, OK. Could you try the following patch instead? If you have a
similar problem with (say) pthread_rwlockattr_t, you
On 20/09/10 07:21, Paul Eggert wrote:
> On 09/19/2010 07:43 PM, Gary V. Vaughan wrote:
>> my system headers have no pthread_spinlock_t definition, but
>> gnulib sees /usr/include/pthread.h and uses that instead of generating it's
>> own,
>> ...
>> I don't know enough about pthreads to tell whethe
Hi Paul,
> If MacOS doesn't have spinlocks, then from coreutils' point of view MacOS
> doesn't have proper thread support.
Usually in applications mutexes are used, not spinlocks. The comments in sort.c
say:
"Note spin locks were seen to perform better than mutexes
as long as the number of
Hi Paul,
Thanks for looking at this.
On 20 Sep 2010, at 13:21, Paul Eggert wrote:
> On 09/19/2010 07:43 PM, Gary V. Vaughan wrote:
>> my system headers have no pthread_spinlock_t definition, but
>> gnulib sees /usr/include/pthread.h and uses that instead of generating it's
>> own,
>> ...
>> I do
On 09/19/2010 07:43 PM, Gary V. Vaughan wrote:
> my system headers have no pthread_spinlock_t definition, but
> gnulib sees /usr/include/pthread.h and uses that instead of generating it's
> own,
> ...
> I don't know enough about pthreads to tell whether gnulib should paper over
> the lack of spin
While testing my rewrite of gnulib's bootstrap script, I've been
unable to rebuild coreutils from git master. However, when I
reverted to a fresh checkout and used the repo bootstrap script,
the build still fails on my Mac:
../../src/sort.c:243: error: expected specifier-qualifier-list before
'p
23 matches
Mail list logo
