GNU bug report logs - #7073
no pthread_spinlock_t on Mac OS 10.6.4

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Chen Guo <chen.guo.0625 <at> gmail.com>, bug-gnulib List <bug-gnulib <at> gnu.org>, bug-coreutils <at> gnu.org, "Gary V. Vaughan" <gary <at> gnu.org>
Subject: bug#7073: no pthread_spinlock_t on Mac OS 10.6.4
Date: Mon, 20 Sep 2010 10:33:34 +0100

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 whether gnulib should paper over
>> the lack of spinlocks on Mac OS, or whether coreutils should be more careful
>> about using spinlocks without having tested for them first...
> 
> If MacOS doesn't have spinlocks, then from coreutils' point of view MacOS
> doesn't have proper thread support.  The simplest fix is for coreutils
> to use the substitute pthread.h on MacOS.  Does the following patch
> work for you?

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.
If we don't end up moving to mutexes everywhere,
perhaps we should do it for Mac OS always?

Also on the same point of more appropriate use
of system resources, perhaps we should cap the
number of cores used to perhaps 8 given results like:
http://debbugs.gnu.org/cgi/bugreport.cgi?msg=49;filename=sort-amd-24way.png;att=1;bug=6600
We would allow increasing up to the number of cores
available on the system by user specified values
(which currently only support decreasing from #cores).

cheers,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.