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

From: Jeff King <peff@peff.net>
Date: Oct 27, 2018, 08:15 UTC
Message-ID: <20181027081538.GG26685@sigill.intra.peff.net>
In-Reply-To: <CACsJy8AA8ABmV5myBEETWP0uSNNFjvUP5mE705OV9=JtyHgTkg@mail.gmail.com>

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

Show 13 quoted lines

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

Show 5 quoted lines

> 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