git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
* [PATCH 0/1] trace2: fix tracing when NO_PTHREADS is defined
@ 2019-05-21 19:33 Jeff Hostetler via GitGitGadget
  2019-05-21 19:33 ` [PATCH 1/1] " Jeff Hostetler via GitGitGadget
  2019-05-21 21:27 ` [PATCH 0/1] " Jeff King
  0 siblings, 2 replies; 10+ messages in thread
From: Jeff Hostetler via GitGitGadget @ 2019-05-21 19:33 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

This commit addresses the problem reported in:
https://public-inbox.org/git/92cfdf43-8841-9c5a-7838-dda995038908@jeffhostetler.com/T/#mbaf8069f6d1bc18d5a02d3682a1f9282f5547ea9

As Duy suggested, pthread_getspecific() just returns NULL when NO_PTHREADS
is defined. And pthread_setspecific() silently does not nothing. So this
problem was hidden from view.

I have to wonder if we should update pthread_*specific() to call BUG() when
NO_PTHREADS is defined as a way to catch unguarded usages easier or make
this issue more clear.

Jeff Hostetler (1):
  trace2: fix tracing when NO_PTHREADS is defined

 trace2/tr2_tls.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)


base-commit: aa25c82427ae70aebf3b8f970f2afd54e9a2a8c6
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-222%2Fjeffhostetler%2Ftrace2-no-pthread-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-222/jeffhostetler/trace2-no-pthread-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/222
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH 1/1] trace2: fix tracing when NO_PTHREADS is defined
  2019-05-21 19:33 [PATCH 0/1] trace2: fix tracing when NO_PTHREADS is defined Jeff Hostetler via GitGitGadget
@ 2019-05-21 19:33 ` Jeff Hostetler via GitGitGadget
  2019-05-21 21:27 ` [PATCH 0/1] " Jeff King
  1 sibling, 0 replies; 10+ messages in thread
From: Jeff Hostetler via GitGitGadget @ 2019-05-21 19:33 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Jeff Hostetler

From: Jeff Hostetler <jeffhost@microsoft.com>

Teach trace2 TLS code to not rely on pthread_getspecific() when NO_PTHREADS
is defined.  Instead, always assume the context data of the main thread.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
---
 trace2/tr2_tls.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/trace2/tr2_tls.c b/trace2/tr2_tls.c
index e76d8c5d92..067c23755f 100644
--- a/trace2/tr2_tls.c
+++ b/trace2/tr2_tls.c
@@ -61,7 +61,12 @@ struct tr2tls_thread_ctx *tr2tls_create_self(const char *thread_name,
 
 struct tr2tls_thread_ctx *tr2tls_get_self(void)
 {
-	struct tr2tls_thread_ctx *ctx = pthread_getspecific(tr2tls_key);
+	struct tr2tls_thread_ctx *ctx;
+
+	if (!HAVE_THREADS)
+		return tr2tls_thread_main;
+
+	ctx = pthread_getspecific(tr2tls_key);
 
 	/*
 	 * If the thread-proc did not call trace2_thread_start(), we won't
@@ -76,9 +81,10 @@ struct tr2tls_thread_ctx *tr2tls_get_self(void)
 
 int tr2tls_is_main_thread(void)
 {
-	struct tr2tls_thread_ctx *ctx = pthread_getspecific(tr2tls_key);
+	if (!HAVE_THREADS)
+		return 1;
 
-	return ctx == tr2tls_thread_main;
+	return pthread_getspecific(tr2tls_key) == tr2tls_thread_main;
 }
 
 void tr2tls_unset_self(void)
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 0/1] trace2: fix tracing when NO_PTHREADS is defined
  2019-05-21 19:33 [PATCH 0/1] trace2: fix tracing when NO_PTHREADS is defined Jeff Hostetler via GitGitGadget
  2019-05-21 19:33 ` [PATCH 1/1] " Jeff Hostetler via GitGitGadget
@ 2019-05-21 21:27 ` Jeff King
  2019-05-22 13:23   ` Jeff Hostetler
  1 sibling, 1 reply; 10+ messages in thread
From: Jeff King @ 2019-05-21 21:27 UTC (permalink / raw)
  To: Jeff Hostetler via GitGitGadget
  Cc: Jeff Hostetler, Nguyễn Thái Ngọc Duy, git,
	Junio C Hamano

On Tue, May 21, 2019 at 12:33:58PM -0700, Jeff Hostetler via GitGitGadget wrote:

> As Duy suggested, pthread_getspecific() just returns NULL when NO_PTHREADS
> is defined. And pthread_setspecific() silently does not nothing. So this
> problem was hidden from view.
> 
> I have to wonder if we should update pthread_*specific() to call BUG() when
> NO_PTHREADS is defined as a way to catch unguarded usages easier or make
> this issue more clear.

I think it should actually store the data asked for by the caller, as if
we were the single thread running. We discussed this as the time of
refactoring NO_PTHREADS, but there was only one caller that would have
benefited. Now there are two. ;)

Discussion in the subthread of this patch:

  https://public-inbox.org/git/20181027071003.1347-2-pclouds@gmail.com/

-Peff

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 0/1] trace2: fix tracing when NO_PTHREADS is defined
  2019-05-21 21:27 ` [PATCH 0/1] " Jeff King
@ 2019-05-22 13:23   ` Jeff Hostetler
  2019-05-23  5:51     ` Jeff King
  2019-05-28 17:14     ` Junio C Hamano
  0 siblings, 2 replies; 10+ messages in thread
From: Jeff Hostetler @ 2019-05-22 13:23 UTC (permalink / raw)
  To: Jeff King, Jeff Hostetler via GitGitGadget
  Cc: Jeff Hostetler, Nguyễn Thái Ngọc Duy, git,
	Junio C Hamano



On 5/21/2019 5:27 PM, Jeff King wrote:
> On Tue, May 21, 2019 at 12:33:58PM -0700, Jeff Hostetler via GitGitGadget wrote:
> 
>> As Duy suggested, pthread_getspecific() just returns NULL when NO_PTHREADS
>> is defined. And pthread_setspecific() silently does not nothing. So this
>> problem was hidden from view.
>>
>> I have to wonder if we should update pthread_*specific() to call BUG() when
>> NO_PTHREADS is defined as a way to catch unguarded usages easier or make
>> this issue more clear.
> 
> I think it should actually store the data asked for by the caller, as if
> we were the single thread running. We discussed this as the time of
> refactoring NO_PTHREADS, but there was only one caller that would have
> benefited. Now there are two. ;)
> 
> Discussion in the subthread of this patch:
> 
>    https://public-inbox.org/git/20181027071003.1347-2-pclouds@gmail.com/
> 
> -Peff
> 

I was wondering about that too as the proper long term solution.
We would need (as the discussion suggests [1]) to properly
respect/represent the pthread_key_t argument.

For now, I've guarded my usage of pthread_getspecific() in the trace2
(similar to what index-pack does), so its not urgent that we update it.
And I'd rather we take this simple trace2 fix now and not try to combine
it with fixes for the pthread macros.  Especially now as we're in the RC
cycle for 2.22.

I'll make a note to revisit the pthread code after 2.22.

Thanks
Jeff


[1] 
https://public-inbox.org/git/CACsJy8DLW_smOJd6aCoRcJZxQ2Lzut5US=sPadj7=fhne0UHGg@mail.gmail.com/


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 0/1] trace2: fix tracing when NO_PTHREADS is defined
  2019-05-22 13:23   ` Jeff Hostetler
@ 2019-05-23  5:51     ` Jeff King
  2019-05-23 13:55       ` Jeff Hostetler
  2019-05-25 10:43       ` Duy Nguyen
  2019-05-28 17:14     ` Junio C Hamano
  1 sibling, 2 replies; 10+ messages in thread
From: Jeff King @ 2019-05-23  5:51 UTC (permalink / raw)
  To: Jeff Hostetler
  Cc: Jeff Hostetler via GitGitGadget, Jeff Hostetler,
	Nguyễn Thái Ngọc Duy, git, Junio C Hamano

On Wed, May 22, 2019 at 09:23:39AM -0400, Jeff Hostetler wrote:

> I was wondering about that too as the proper long term solution.
> We would need (as the discussion suggests [1]) to properly
> respect/represent the pthread_key_t argument.
> 
> For now, I've guarded my usage of pthread_getspecific() in the trace2
> (similar to what index-pack does), so its not urgent that we update it.
> And I'd rather we take this simple trace2 fix now and not try to combine
> it with fixes for the pthread macros.  Especially now as we're in the RC
> cycle for 2.22.

Yeah, I think that makes sense.

> I'll make a note to revisit the pthread code after 2.22.

For fun, here's a constant-time zero-allocation implementation that I
came up with. It passes t0211 with NO_PTHREADS, but I didn't test it
beyond that.

diff --git a/thread-utils.h b/thread-utils.h
index 4961487ed9..f466215742 100644
--- a/thread-utils.h
+++ b/thread-utils.h
@@ -18,7 +18,7 @@
 #define pthread_t int
 #define pthread_mutex_t int
 #define pthread_cond_t int
-#define pthread_key_t int
+#define pthread_key_t git_pthread_key_t
 
 #define pthread_mutex_init(mutex, attr) dummy_pthread_init(mutex)
 #define pthread_mutex_lock(mutex)
@@ -31,16 +31,49 @@
 #define pthread_cond_broadcast(cond)
 #define pthread_cond_destroy(cond)
 
-#define pthread_key_create(key, attr) dummy_pthread_init(key)
-#define pthread_key_delete(key)
+#define pthread_key_create(key, destroy) git_pthread_key_create(key, destroy)
+#define pthread_key_delete(key) git_pthread_key_delete(key)
 
 #define pthread_create(thread, attr, fn, data) \
 	dummy_pthread_create(thread, attr, fn, data)
 #define pthread_join(thread, retval) \
 	dummy_pthread_join(thread, retval)
 
-#define pthread_setspecific(key, data)
-#define pthread_getspecific(key) NULL
+#define pthread_setspecific(key, data) git_pthread_setspecific(key, data)
+#define pthread_getspecific(key) git_pthread_getspecific(key)
+
+typedef struct {
+	void *data;
+	/* extra indirection because setspecific is passed key by value */
+	void **vdata;
+} git_pthread_key_t;
+
+static inline int git_pthread_key_create(git_pthread_key_t *key,
+					 void (*destroy)(void *))
+{
+	key->data = NULL;
+	key->vdata = &key->data;
+	/* We don't use this; alternatively we could all via atexit(). */
+	if (destroy)
+		BUG("NO_PTHREADS does not support pthread key destructors");
+	return 0;
+}
+
+static inline int git_pthread_key_delete(git_pthread_key_t key)
+{
+	/* noop */
+	return 0;
+}
+
+static inline void git_pthread_setspecific(git_pthread_key_t key, void *data)
+{
+	*(key.vdata) = data;
+}
+
+static inline void *git_pthread_getspecific(git_pthread_key_t key)
+{
+	return key.data;
+}
 
 int dummy_pthread_create(pthread_t *pthread, const void *attr,
 			 void *(*fn)(void *), void *data);

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 0/1] trace2: fix tracing when NO_PTHREADS is defined
  2019-05-23  5:51     ` Jeff King
@ 2019-05-23 13:55       ` Jeff Hostetler
  2019-05-25 10:43       ` Duy Nguyen
  1 sibling, 0 replies; 10+ messages in thread
From: Jeff Hostetler @ 2019-05-23 13:55 UTC (permalink / raw)
  To: Jeff King
  Cc: Jeff Hostetler via GitGitGadget, Jeff Hostetler,
	Nguyễn Thái Ngọc Duy, git, Junio C Hamano



On 5/23/2019 1:51 AM, Jeff King wrote:
> On Wed, May 22, 2019 at 09:23:39AM -0400, Jeff Hostetler wrote:
> 
>> I was wondering about that too as the proper long term solution.
>> We would need (as the discussion suggests [1]) to properly
>> respect/represent the pthread_key_t argument.
>>
>> For now, I've guarded my usage of pthread_getspecific() in the trace2
>> (similar to what index-pack does), so its not urgent that we update it.
>> And I'd rather we take this simple trace2 fix now and not try to combine
>> it with fixes for the pthread macros.  Especially now as we're in the RC
>> cycle for 2.22.
> 
> Yeah, I think that makes sense.
> 
>> I'll make a note to revisit the pthread code after 2.22.
> 
> For fun, here's a constant-time zero-allocation implementation that I
> came up with. It passes t0211 with NO_PTHREADS, but I didn't test it
> beyond that.
> 
> diff --git a/thread-utils.h b/thread-utils.h
> index 4961487ed9..f466215742 100644
> --- a/thread-utils.h
> +++ b/thread-utils.h
> @@ -18,7 +18,7 @@
>   #define pthread_t int
>   #define pthread_mutex_t int
>   #define pthread_cond_t int
> -#define pthread_key_t int
> +#define pthread_key_t git_pthread_key_t
>   
>   #define pthread_mutex_init(mutex, attr) dummy_pthread_init(mutex)
>   #define pthread_mutex_lock(mutex)
> @@ -31,16 +31,49 @@
>   #define pthread_cond_broadcast(cond)
>   #define pthread_cond_destroy(cond)
>   
> -#define pthread_key_create(key, attr) dummy_pthread_init(key)
> -#define pthread_key_delete(key)
> +#define pthread_key_create(key, destroy) git_pthread_key_create(key, destroy)
> +#define pthread_key_delete(key) git_pthread_key_delete(key)
>   
>   #define pthread_create(thread, attr, fn, data) \
>   	dummy_pthread_create(thread, attr, fn, data)
>   #define pthread_join(thread, retval) \
>   	dummy_pthread_join(thread, retval)
>   
> -#define pthread_setspecific(key, data)
> -#define pthread_getspecific(key) NULL
> +#define pthread_setspecific(key, data) git_pthread_setspecific(key, data)
> +#define pthread_getspecific(key) git_pthread_getspecific(key)
> +
> +typedef struct {
> +	void *data;
> +	/* extra indirection because setspecific is passed key by value */
> +	void **vdata;
> +} git_pthread_key_t;
> +
> +static inline int git_pthread_key_create(git_pthread_key_t *key,
> +					 void (*destroy)(void *))
> +{
> +	key->data = NULL;
> +	key->vdata = &key->data;
> +	/* We don't use this; alternatively we could all via atexit(). */
> +	if (destroy)
> +		BUG("NO_PTHREADS does not support pthread key destructors");
> +	return 0;
> +}
> +
> +static inline int git_pthread_key_delete(git_pthread_key_t key)
> +{
> +	/* noop */
> +	return 0;
> +}
> +
> +static inline void git_pthread_setspecific(git_pthread_key_t key, void *data)
> +{
> +	*(key.vdata) = data;
> +}
> +
> +static inline void *git_pthread_getspecific(git_pthread_key_t key)
> +{
> +	return key.data;
> +}
>   
>   int dummy_pthread_create(pthread_t *pthread, const void *attr,
>   			 void *(*fn)(void *), void *data);
> 

Thanks!  I'll play with this and submit something after 2.22 and
things slow down a bit.

Jeff


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 0/1] trace2: fix tracing when NO_PTHREADS is defined
  2019-05-23  5:51     ` Jeff King
  2019-05-23 13:55       ` Jeff Hostetler
@ 2019-05-25 10:43       ` Duy Nguyen
  2019-05-28  6:28         ` Jeff King
  1 sibling, 1 reply; 10+ messages in thread
From: Duy Nguyen @ 2019-05-25 10:43 UTC (permalink / raw)
  To: Jeff King
  Cc: Jeff Hostetler, Jeff Hostetler via GitGitGadget, Jeff Hostetler,
	Git Mailing List, Junio C Hamano

On Thu, May 23, 2019 at 12:51 PM Jeff King <peff@peff.net> wrote:
> For fun, here's a constant-time zero-allocation implementation that I
> came up with. It passes t0211 with NO_PTHREADS, but I didn't test it
> beyond that.
>
> diff --git a/thread-utils.h b/thread-utils.h
> index 4961487ed9..f466215742 100644
> --- a/thread-utils.h
> +++ b/thread-utils.h
> @@ -18,7 +18,7 @@
>  #define pthread_t int
>  #define pthread_mutex_t int
>  #define pthread_cond_t int
> -#define pthread_key_t int
> +#define pthread_key_t git_pthread_key_t
>
>  #define pthread_mutex_init(mutex, attr) dummy_pthread_init(mutex)
>  #define pthread_mutex_lock(mutex)
> @@ -31,16 +31,49 @@
>  #define pthread_cond_broadcast(cond)
>  #define pthread_cond_destroy(cond)
>
> -#define pthread_key_create(key, attr) dummy_pthread_init(key)
> -#define pthread_key_delete(key)
> +#define pthread_key_create(key, destroy) git_pthread_key_create(key, destroy)
> +#define pthread_key_delete(key) git_pthread_key_delete(key)
>
>  #define pthread_create(thread, attr, fn, data) \
>         dummy_pthread_create(thread, attr, fn, data)
>  #define pthread_join(thread, retval) \
>         dummy_pthread_join(thread, retval)
>
> -#define pthread_setspecific(key, data)
> -#define pthread_getspecific(key) NULL
> +#define pthread_setspecific(key, data) git_pthread_setspecific(key, data)
> +#define pthread_getspecific(key) git_pthread_getspecific(key)
> +
> +typedef struct {
> +       void *data;
> +       /* extra indirection because setspecific is passed key by value */
> +       void **vdata;

Ha! I was thinking a separate key->value mapping which is complicated
in C. But this works pretty well for a single thread, and it even
supports multiple keys.

> +} git_pthread_key_t;
> +
> +static inline int git_pthread_key_create(git_pthread_key_t *key,
> +                                        void (*destroy)(void *))
> +{
> +       key->data = NULL;
> +       key->vdata = &key->data;
> +       /* We don't use this; alternatively we could all via atexit(). */
> +       if (destroy)
> +               BUG("NO_PTHREADS does not support pthread key destructors");
> +       return 0;
> +}
> +
> +static inline int git_pthread_key_delete(git_pthread_key_t key)
> +{
> +       /* noop */
> +       return 0;
> +}
> +
> +static inline void git_pthread_setspecific(git_pthread_key_t key, void *data)
> +{
> +       *(key.vdata) = data;
> +}
> +
> +static inline void *git_pthread_getspecific(git_pthread_key_t key)
> +{
> +       return key.data;
> +}
>
>  int dummy_pthread_create(pthread_t *pthread, const void *attr,
>                          void *(*fn)(void *), void *data);
-- 
Duy

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 0/1] trace2: fix tracing when NO_PTHREADS is defined
  2019-05-25 10:43       ` Duy Nguyen
@ 2019-05-28  6:28         ` Jeff King
  2019-05-28 14:57           ` Jeff Hostetler
  0 siblings, 1 reply; 10+ messages in thread
From: Jeff King @ 2019-05-28  6:28 UTC (permalink / raw)
  To: Duy Nguyen
  Cc: Jeff Hostetler, Jeff Hostetler via GitGitGadget, Jeff Hostetler,
	Git Mailing List, Junio C Hamano

On Sat, May 25, 2019 at 05:43:55PM +0700, Duy Nguyen wrote:

> > +typedef struct {
> > +       void *data;
> > +       /* extra indirection because setspecific is passed key by value */
> > +       void **vdata;
> 
> Ha! I was thinking a separate key->value mapping which is complicated
> in C. But this works pretty well for a single thread, and it even
> supports multiple keys.

I really wish that all of the functions passed the pthread_key_t by
reference. That would make it possible to define the key as a single
pointer.

I'm not sure if pthread_key_t's are meant to be shallow-copyable. I.e.,
should this work:

  void foo(pthread_key_t *out)
  {
	pthread_key_t tmp;
	pthread_key_create(&tmp, NULL);
	*out = tmp;
  }
  ...
  pthread_key_t k;
  foo(&k);
  pthread_setspecific(k, some_ptr);

It does not with my proposed plan, because the pointer in tmp.data went
out of scope, leaving tmp.vdata (and thus k.vdata) as a dangling
pointer.

The code above seems like a vaguely crazy thing to do. But if we want to
be absolutely paranoid, we'd have to malloc() an extra pointer in the
create() function, instead of carrying it inside the key. Or just make a
global "void *thread_specific_data[PTHREAD_KEYS_MAX]" and make each key
an integer index into it.

It's pretty clear that they expect one of those two implementations,
given that POSIX says key creation can report either ENOMEM, or EAGAIN
if we exceed PTHREAD_KEYS_MAX. :)

-Peff

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 0/1] trace2: fix tracing when NO_PTHREADS is defined
  2019-05-28  6:28         ` Jeff King
@ 2019-05-28 14:57           ` Jeff Hostetler
  0 siblings, 0 replies; 10+ messages in thread
From: Jeff Hostetler @ 2019-05-28 14:57 UTC (permalink / raw)
  To: Jeff King, Duy Nguyen
  Cc: Jeff Hostetler via GitGitGadget, Jeff Hostetler,
	Git Mailing List, Junio C Hamano



On 5/28/2019 2:28 AM, Jeff King wrote:
> On Sat, May 25, 2019 at 05:43:55PM +0700, Duy Nguyen wrote:
> 
>>> +typedef struct {
>>> +       void *data;
>>> +       /* extra indirection because setspecific is passed key by value */
>>> +       void **vdata;
>>
>> Ha! I was thinking a separate key->value mapping which is complicated
>> in C. But this works pretty well for a single thread, and it even
>> supports multiple keys.
> 
> I really wish that all of the functions passed the pthread_key_t by
> reference. That would make it possible to define the key as a single
> pointer.
> 
> I'm not sure if pthread_key_t's are meant to be shallow-copyable. I.e.,
> should this work:
> 
>    void foo(pthread_key_t *out)
>    {
> 	pthread_key_t tmp;
> 	pthread_key_create(&tmp, NULL);
> 	*out = tmp;
>    }
>    ...
>    pthread_key_t k;
>    foo(&k);
>    pthread_setspecific(k, some_ptr);
> 
> It does not with my proposed plan, because the pointer in tmp.data went
> out of scope, leaving tmp.vdata (and thus k.vdata) as a dangling
> pointer.
> 
> The code above seems like a vaguely crazy thing to do. But if we want to
> be absolutely paranoid, we'd have to malloc() an extra pointer in the
> create() function, instead of carrying it inside the key. Or just make a
> global "void *thread_specific_data[PTHREAD_KEYS_MAX]" and make each key
> an integer index into it.
> 
> It's pretty clear that they expect one of those two implementations,
> given that POSIX says key creation can report either ENOMEM, or EAGAIN
> if we exceed PTHREAD_KEYS_MAX. :)
> 
> -Peff
> 


Yes, a fixed global void* array should be fine.
Besides there aren't that many calls to pthread_key_create()  (My use in
Trace2 is the second, right?), so just create an arbitrary value for
PTHREAD_KEYS_MAX and be done.


Jeff

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH 0/1] trace2: fix tracing when NO_PTHREADS is defined
  2019-05-22 13:23   ` Jeff Hostetler
  2019-05-23  5:51     ` Jeff King
@ 2019-05-28 17:14     ` Junio C Hamano
  1 sibling, 0 replies; 10+ messages in thread
From: Junio C Hamano @ 2019-05-28 17:14 UTC (permalink / raw)
  To: Jeff Hostetler
  Cc: Jeff King, Jeff Hostetler via GitGitGadget, Jeff Hostetler,
	Nguyễn Thái Ngọc Duy, git

Jeff Hostetler <git@jeffhostetler.com> writes:

> For now, I've guarded my usage of pthread_getspecific() in the trace2
> (similar to what index-pack does), so its not urgent that we update it.
> And I'd rather we take this simple trace2 fix now and not try to combine
> it with fixes for the pthread macros.  Especially now as we're in the RC
> cycle for 2.22.
>
> I'll make a note to revisit the pthread code after 2.22.

Thanks, both.  The above direction makes sense for me, too.


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2019-05-28 17:14 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-21 19:33 [PATCH 0/1] trace2: fix tracing when NO_PTHREADS is defined Jeff Hostetler via GitGitGadget
2019-05-21 19:33 ` [PATCH 1/1] " Jeff Hostetler via GitGitGadget
2019-05-21 21:27 ` [PATCH 0/1] " Jeff King
2019-05-22 13:23   ` Jeff Hostetler
2019-05-23  5:51     ` Jeff King
2019-05-23 13:55       ` Jeff Hostetler
2019-05-25 10:43       ` Duy Nguyen
2019-05-28  6:28         ` Jeff King
2019-05-28 14:57           ` Jeff Hostetler
2019-05-28 17:14     ` Junio C Hamano

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git