doesn't pick up existing threads at launch

[gedalia]

I just noticed that viztracer can't capture already running threads, only ones that have launched after tracing has started. seems like it would be a nice addition. Looks like 3.12 might have added functions that would enable it to happen (see threading.settrace_all_threads)

[gaogaotiantian]

So there are two issues.

First of all, viztracer tries to support all python versions that are not EOL and make the behavior consistent on them. Having something that only works on 3.12 is not impossible, but should be justified well enough.

In this specific case, if your thread already started, you can be at any depth in your stack and it's kind of weird to start recording from there. The more important reason is, viztracer is supposed be used as a CLI program, inline usage is not first citizen. Plenty of features won't work if you use it inline - multiprocessing support for example. So I'm trying to make inline usage work for simple cases, a quick trace for some simply scripts, but to utilize it to its full capability, you should use CLI.

[gedalia]

I was imagining hasattr could be used to decide if a feature was available, we're actually on 3.10 not 3.12, but figured I could be forward looking. It's interesting that you think of it as a mainly CLI tool. I have it hooked into our gui so it can be started and stopped at will, in general I frequently only get a second or two of info before I blow through the buffer, so there's no way I could use the CLI.
I often use the tools like this just to understand systems I'm not that familiar with, works a bit better with https://github.com/wolfpld/tracy which can handle much larger captures.

[gaogaotiantian]

I'm not saying this is unsolvable. I'm just not sure tracing at an arbitrary point of a thread generates good data.

I do think of it as a CLI tool, because all the multi-process features rely on it anyway. You won't be able to trace multiprocess programs with inline usage.

The tool probaly will be a bit confused (not a lot) if you have return events that do not correspond to a start (imagine you are deep in the call stack and you start the tracing).

However, if you do want something like that, maybe try to create a single tracer as soon as your GUI started - it will hook the threadings. Then use start() and stop() to collect trace, instead of creating a new tracer every time the user wants to trace.

[gedalia]

hm that's an interesting idea that I hadn't realized was possible, will give it a try