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

Mon Jun 19 06:56:10 PDT 2017

ravitheja added a comment.

In https://reviews.llvm.org/D33674#783893, @labath wrote:

> In https://reviews.llvm.org/D33674#783861, @ravitheja wrote:
>
> > Although a bit confusing, there is more flexibility for the user.I must also point out that the trace buffer available is not unlimited and there can be situations where a user might simultaneously want to trace newly spawned threads with a smaller buffer and trace an individual thread with perhaps a bigger buffer size.  Tracing all threads is definitely important coz the user might not want to separately start tracing on each new thread. Now the current design might be a bit confusing but I am willing to document it well with examples and uses cases.
>
>
> I agree that having the ability to trace new threads from the moment they spawn is important. The confusion arises from the fact that we are treating "trace all threads" and "trace new threads" as a single concept. I think the cleanest solution for me would be to split those up, so that we would have three operations: (1) trace a specific thread, (2) trace new threads, (3) trace all threads. Then (1) and (2) can be combined in arbitrary ways, and (3) is mutually exclusive with anything else. It could be I am over-designing this though. I'd like to hear the opinion of anyone else that is reading this.

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.

https://reviews.llvm.org/D33674