Jeff King <p...@peff.net> writes:

> What we really need is thread-local storage for
> packet_trace_identity. But the async code does not provide
> an interface for that, and it would be messy to add it here
> (we'd have to care about pthreads, initializing our
> pthread_key_t ahead of time, etc).

True.

> So instead, let us just assume that any async process is
> handling sideband data. That's always true now, and is
> likely to remain so in the future.

Hmm, does Stefan's thread-pool thing interact with this decision in
any way?
>
> The output looks like:
>
>    packet:  sideband< \1000eunpack ok0019ok refs/heads/master0000
>    packet:      push< unpack ok
>    packet:      push< ok refs/heads/master
>    packet:      push< 0000
>    packet:  sideband< 0000
>
> Signed-off-by: Jeff King <p...@peff.net>
> ---
>  pkt-line.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/pkt-line.c b/pkt-line.c
> index 08a1427..62fdb37 100644
> --- a/pkt-line.c
> +++ b/pkt-line.c
> @@ -1,5 +1,6 @@
>  #include "cache.h"
>  #include "pkt-line.h"
> +#include "run-command.h"
>  
>  char packet_buffer[LARGE_PACKET_MAX];
>  static const char *packet_trace_prefix = "git";
> @@ -11,6 +12,11 @@ void packet_trace_identity(const char *prog)
>       packet_trace_prefix = xstrdup(prog);
>  }
>  
> +static const char *get_trace_prefix(void)
> +{
> +     return in_async() ? "sideband" : packet_trace_prefix;
> +}
> +
>  static int packet_trace_pack(const char *buf, unsigned int len, int sideband)
>  {
>       if (!sideband) {
> @@ -57,7 +63,7 @@ static void packet_trace(const char *buf, unsigned int len, 
> int write)
>       strbuf_init(&out, len+32);
>  
>       strbuf_addf(&out, "packet: %12s%c ",
> -                 packet_trace_prefix, write ? '>' : '<');
> +                 get_trace_prefix(), write ? '>' : '<');
>  
>       /* XXX we should really handle printable utf8 */
>       for (i = 0; i < len; i++) {
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to