-
-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doesn't pick up existing threads at launch #437
Comments
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. |
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'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 |
hm that's an interesting idea that I hadn't realized was possible, will give it a try |
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)
The text was updated successfully, but these errors were encountered: