Mechanism to detect new threads#88
Conversation
|
Amazing. Will look at this soon! |
|
Thanks! Do you think this should be an option? E.g., if someone starts profiling but later decides to attach a debugger, this will now not be possible AIUI. Though, I guess the old behavior is still possible if you just select all threads and profile with those threads. Maybe we only need to document it. |
|
If the debugger interface doesn't work out, I believe another option is to inject a custom mini DLL into the target's address space -- you can get thread creation notifications via its DllMain callback. |
Yes, my thinking was that you get the old behavior by selecting all existing threads and profiling them |
It works on my machine!!1 |
… interferes with the operation of Suspend/ResumeThread().
|
Yep, I think a note in the documentation should be enough. We can update the wiki after this is merged. LGTM, I rebased on master and added a changelog entry. Let me know if that looks OK to you and we can merge. |
|
It looks great, thank you :) |
|
I also looked into how to make this work through dll injection. RenderDoc does this in production code, here's the code https://github.com/baldurk/renderdoc/blob/v1.x/renderdoc/os/win32/win32_process.cpp#L252-L297 |
Use windows debugger interface to detect the debugee's threads.
Fall back to polling a toolhelp snapshot in case debugger interface can't attach of fails.
Fixes #4