[Lldb-commits] [PATCH] D33674: Implementation of Intel(R) Processor Trace support for Linux

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

> Well that's the whole thread group idea. Currently we have only one thread group i.e the process group (all existing un traced threads + newly spawned ones).
>  With separate "trace all threads" and "trace new threads", it will be multiple thread groups. For e.g
> 
> Lets say an application spawns 10 threads, now here we can end up with 9 thread groups in the worst case if the user calls  "trace all threads" after each
>  new spawned thread.
> 
> Now I wanted to avoid having multiple thread groups coz the implementation will become more complex.

That's not exactly how I imagined it. Calling "trace all threads" could still only be done once. You can only combine tracing a single thread and tracing newly created threads. So you could end up with ~10 trace instances, if you start tracing threads one by one, but the user would probably give up after the first two, and just start tracing all future threads in once instance.

However, this talk of groups has interested me. If we phrase it in terms of groups, I think the current behavior makes some sense -- the user can create a "group trace", and this group would contain all current untraced threads, as well as any threads that are created in the future. If noone else has any opinion on this, then I guess we can go with this. We should just make sure to document it and avoid function names like "trace_ALL_threads" and similar. :)


https://reviews.llvm.org/D33674