Re: [PATCH 01/10] thread-utils: macros to unconditionally compile pthreads API

From: Jeff King <peff@peff.net>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Ben Peart <peartben@gmail.com>
Subject: Re: [PATCH 01/10] thread-utils: macros to unconditionally compile pthreads API
Date: Sat, 27 Oct 2018 04:15:39 -0400	[thread overview]
Message-ID: <20181027081538.GG26685@sigill.intra.peff.net> (raw)
In-Reply-To: <CACsJy8AA8ABmV5myBEETWP0uSNNFjvUP5mE705OV9=JtyHgTkg@mail.gmail.com>

On Sat, Oct 27, 2018 at 09:40:13AM +0200, Duy Nguyen wrote:

> > We expect to be able to store a void pointer here and get it back, which
> > should work even for a single thread. Do we need something like:
> >
> >   extern void *pthread_specific_data;
> >
> >   #define pthread_setspecific(key, data) do { \
> >         pthread_specific_data = data; \
> >   } while(0)
> >
> >   void pthread_getspecific(key) pthread_specific_data
> 
> The data is per key though so a correct implementation may involve a
> hashmap or a list.

Ah, yeah, you're right, I was mixing up the thread id and the key in my
head. I think it would just be an array of void pointers, with
pthread_key_create() returning an static index.

> It does simplify index-pack which has to fall back to nothread_data
> when pthreads is not available. But with index-pack being the only
> call site that can take advantage of this (run-command.c probably will
> use real pthreads library anyway), I'm not sure if it's worth really
> implementing these functions.

Yeah, you might be right.

-Peff