[Feature request] Initialisation of NodeMatrix member variables

[mdavis670]

Describe the problem you're solving

I'm using the profiler code as a basis for measuring co-routines (seastar). This means I'm using a version of ThreadCallGraph that's stack based rather than thread_local.

Describe the solution you'd like

The member variables of NodeMatrix don't get initialised to zero when using a stack based version of ThreadCallGraph and should be set to 0 in the header file (profiler.hpp) to avoid this problem.

[DmitriBogdanov]

Curios use case, indeed can't rely on thread_local zero-initialization here. Should be resolved by f8128de.

[mdavis670]

Thanks for the patch.

We want to record the runtime-stack trace of each function that runs in a "seastar shard" (co-operative thread with a scheduler).

As an example, we might queue up a particular functor to the queue followed by another with, perhaps, the same functor but different instance. However... due to co_await calls and the scheduler, they both might be switching stacks between each other as they're run "concurrently" on the same thread.

Naturally, we don't want the calls to functions mixed up and to have them independently recorded.

FYI, it's working. If the company legal folks allow me, I'll send you the work so you can take a look at it. If you aren't interested, we'll probably put it into a Hitachi-Vantara public repo with a dependency on your code. Hope that seems ok to you?

[DmitriBogdanov]

That is fine by me, glad to see this work useful.

Would be curios to see the adaptation as coroutine usage wasn't really considered during initial development, perhaps it'd be possible to have support for it out of the box.

[mdavis670]

The main differences are that I don't use the thread_local storage values. This meant (copy/paste) of your classes/structs that referred to them and passing in a reference my version of the ThreadCallGraph to my versions. This includes the macros too.

Of note is that the collected results have to be merged based on their thread id and label name so to get an accumulative value for a given stack path. We'd run out of RAM otherwise, of course. A hash of these as a key to the unordered map.

A colleague is also working on getting results out into Grafana so we can see changes over time. JSON output.

If we were to update your version of the code, it'd mostly be passing in a ThreadCallGraph as a parameter in a ctor. You could default that to be the thread_local version. There were a few functions I couldn't call as they were private.

When we've done our work, I'll see if I can get the code to you (as is). It's a lot of copy/paste but would be useful to use as a basis for updating your version to support both modes. I'd be happy to give you an overview of it and some examples.