git/trace2.h, branch v2.40.2

trace2: add global counter mechanism

2022-10-24T19:45:26Z

Add global counters mechanism to Trace2. The Trace2 counters mechanism adds the ability to create a set of global counter variables and an API to increment them efficiently. Counters can optionally report per-thread usage in addition to the sum across all threads. Counter events are emitted to the Trace2 logs when a thread exits and at process exit. Counters are an alternative to `data` and `data_json` events. Counters are useful when you want to measure something across the life of the process, when you don't want per-measurement events for performance reasons, when the data does not fit conveniently within a region, or when your control flow does not easily let you write the final total. For example, you might use this to report the number of calls to unzip() or the number of de-delta steps during a checkout. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

trace2: add stopwatch timers

2022-10-24T19:45:26Z

Add stopwatch timer mechanism to Trace2. Timers are an alternative to Trace2 Regions. Regions are useful for measuring the time spent in various computation phases, such as the time to read the index, time to scan for unstaged files, time to scan for untracked files, and etc. However, regions are not appropriate in all places. For example, during a checkout, it would be very inefficient to use regions to measure the total time spent inflating objects from the ODB from across the entire lifetime of the process; a per-unzip() region would flood the output and significantly slow the command; and some form of post-processing would be requried to compute the time spent in unzip(). Timers can be used to measure a series of timer intervals and emit a single summary event (at thread and/or process exit). Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

trace2: rename the thread_name argument to trace2_thread_start

2022-10-24T19:45:25Z

Rename the `thread_name` argument in `tr2tls_create_self()` and `trace2_thread_start()` to be `thread_base_name` to make it clearer that the passed argument is a component used in the construction of the actual `struct tr2tls_thread_ctx.thread_name` variable. The base name will be used along with the thread id to create a unique thread name. This commit does not change how the `thread_name` field is allocated or stored within the `tr2tls_thread_ctx` structure. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

tr2tls: clarify TLS terminology

2022-10-24T19:45:25Z

Reduce or eliminate use of the term "TLS" in the Trace2 code. The term "TLS" has two popular meanings: "thread-local storage" and "transport layer security". In the Trace2 source, the term is associated with the former. There was concern on the mailing list about it refering to the latter. Update the source and documentation to eliminate the use of the "TLS" term or replace it with the phrase "thread-local storage" to reduce ambiguity. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

common-main.c: move non-trace2 exit() behavior out of trace2.c

2022-06-02T19:51:30Z

Change the exit() wrapper added in ee4512ed481 (trace2: create new combined trace facility, 2019-02-22) so that we'll split up the trace2 logging concerns from wanting to wrap the "exit()" function itself for other purposes. This makes more sense structurally, as we won't seem to conflate non-trace2 behavior with the trace2 code. I'd previously added an explanation for this in 368b5843158 (common-main.c: call exit(), don't return, 2021-12-07), that comment is being adjusted here. Now the only thing we'll do if we're not using trace2 is to truncate the "code" argument to the lowest 8 bits. We only need to do that truncation on non-POSIX systems, but in ee4512ed481 that "if defined(__MINGW32__)" code added in 47e3de0e796 (MinGW: truncate exit()'s argument to lowest 8 bits, 2009-07-05) was made to run everywhere. It might be good for clarify to narrow that down by an "ifdef" again, but I'm not certain that in the interim we haven't had some other non-POSIX systems rely the behavior. On a POSIX system taking the lowest 8 bits is implicit, see exit(3)[1] and wait(2)[2]. Let's leave a comment about that instead. 1. https://man7.org/linux/man-pages/man3/exit.3.html 2. https://man7.org/linux/man-pages/man2/wait.2.html Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

C99: remove hardcoded-out !HAVE_VARIADIC_MACROS code

2022-02-22T03:14:19Z

Remove the "else" branches of the HAVE_VARIADIC_MACROS macro, which have been unconditionally omitted since 765dc168882 (git-compat-util: always enable variadic macros, 2021-01-28). Since were always omitted, anyone trying to use a compiler without variadic macro support to compile a git since version git v2.31.0 or later would have had a compilation error. 10 months across a few releases since then should have been enough time for anyone who cared to run into that and report the issue. In addition to that, for anyone unsetting HAVE_VARIADIC_MACROS we've been emitting extremely verbose warnings since at least ee4512ed481 (trace2: create new combined trace facility, 2019-02-22). That's because there is no such thing as a "region_enter_printf" or "region_leave_printf" format, so at least under GCC and Clang everything that includes trace.h (almost every file) emits a couple of warnings about that. There's a large benefit to being able to have a hard dependency rely on variadic macros, the code surrounding usage.c is hard to maintain if we need to write two implementations of everything, and by relying on "__FILE__" and "__LINE__" along with "__VA_ARGS__" we can in the future make error(), die() etc. log where they were called from. We've also recently merged d67fc4bf0ba (Merge branch 'bc/require-c99', 2021-12-10) which further cements our hard dependency on C99. So let's delete the fallback code, and update our CodingGuidelines to note that we depend on this. The added bullet-point starts with lower-case for consistency with other bullet-points in that section. The diff in "trace.h" is relatively hard to read, since we need to retain the existing API docs, which were comments on the code used if HAVE_VARIADIC_MACROS was not defined. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'jh/builtin-fsmonitor-part1'

2021-10-13T22:15:58Z

Built-in fsmonitor (part 1). * jh/builtin-fsmonitor-part1: t/helper/simple-ipc: convert test-simple-ipc to use start_bg_command run-command: create start_bg_command simple-ipc/ipc-win32: add Windows ACL to named pipe simple-ipc/ipc-win32: add trace2 debugging simple-ipc: move definition of ipc_active_state outside of ifdef simple-ipc: preparations for supporting binary messages. trace2: add trace2_child_ready() to report on background children

Merge branch 'en/typofixes'

2021-09-28T20:06:53Z

Typofixes. * en/typofixes: merge-ort: fix completely wrong comment trace2.h: fix trivial comment typo

trace2.h: fix trivial comment typo

2021-09-20T18:25:01Z

Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

trace2: add trace2_child_ready() to report on background children

2021-09-20T15:57:58Z

Create "child_ready" event to capture the state of a child process created in the background. When a child command is started a "child_start" event is generated in the Trace2 log. For normal synchronous children, a "child_exit" event is later generated when the child exits or is terminated. The two events include information, such as the "child_id" and "pid", to allow post analysis to match-up the command line and exit status. When a child is started in the background (and may outlive the parent process), it is not possible for the parent to emit a "child_exit" event. Create a new "child_ready" event to indicate whether the child was successfully started. Also include the "child_id" and "pid" to allow similar post processing. This will be used in a later commit with the new "start_bg_command()". Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano