Re: bug#7073: no pthread_spinlock_t on Mac OS 10.6.4

[Pádraig Brady]

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.