[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pádraig Brady
Subject: Re: bug#7073: no pthread_spinlock_t on Mac OS 10.6.4
Date: Mon, 20 Sep 2010 10:33:34 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100227 Thunderbird/3.0.3

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:
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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]