Re: [PATCH 27/36] attr: convert to new threadsafe API
- From
Stefan Beller <sbeller@google.com>
- Date
- Oct 26, 2016, 20:46 UTC
- Message-ID
- <CAGZ79kYhMVrKHhNGYcf_D9kWEYp+sC+tMGbuE+gnD8AU27dh8g@mail.gmail.com>
- In-Reply-To
- <6f231a78-5d74-b93f-a644-a4700c9dfbe7@kdbg.org>
On Wed, Oct 26, 2016 at 1:40 PM, Johannes Sixt <j6t@kdbg.org> wrote:
Show 21 quoted lines
> Am 26.10.2016 um 22:26 schrieb Jeff King: >> >> On Wed, Oct 26, 2016 at 10:25:38PM +0200, Johannes Sixt wrote: >> >>> Am 26.10.2016 um 21:51 schrieb Stefan Beller: >>>> >>>> it is >>>> very convenient to not have to explicitly initialize mutexes? >>> >>> >>> Not to initialize a mutex is still wrong for pthreads. >> >> >> I think Stefan was being loose with his wording. There would still be an >> initializer, but it would be a constant (and in the case of pthread >> emulation on Windows, would just be NULL). > > > And I was loose, too: Not to initialize a mutex with at least > PTHREAD_MUTEX_INITILIZER (if not pthread_mutex_init) is still wrong. >
My words were wrong, I meant statically initialized instead of the need to call a function to initialize a mutex. (For the attribute subsystem, where would that function go? We use attrs all over the place. My current thinking would be in git.c to initialize the Big Single Attr Lock. I feel like that is not very well maintainable though).
Sorry for the confusion, Stefan