On Wed, 27 Jun 2018 at 14:11, Zachary Turner <ztur...@google.com> wrote: > > suppose process A (single threaded) is tracing process B (2 threads). If > trace events happen on both threads of B, then the second thread can’t > continue until both threads’ trace events have been fully handled, > synchronously. If process A has a second thread though, the tracer thread can > enqueue work via a lock free queue (or worst case scenario, a mutex), and > continue immediately. So it seems less overhead this way.
I think that depends a lot on the use case. I can certainly see how multithreading would be beneficial if you have a lot of work to do that can be done asynchronously. However, there isn't a ton of other work in lldb-server. We always either wait for the process to stop (in which case we quickly want to gather information and notify the client about that), or we wait for a command from the client (in which case we want to quickly execute it). Threading doesn't help either of those cases. If your tracer is doing some kind of asynchronous processing of the process events (during which the inferior process can continue running) then offloading that to a background thread makes sense. However, even in that case, I think that the collection of the actual data needed for the background processing would be best done synchronously on the ptrace thread because: a) there will be no context switching involved; b) It allows the client to specify exactly the kind of data it wants to collect. Then the collected data can be enqueued to the background thread or whatever, but this does not need to be too tightly integrated with the core APIs. _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev