[lldb-dev] RFC: libtrace

[Pavel Labath via lldb-dev]

On Wed, 27 Jun 2018 at 14:11, Zachary Turner <zturner at 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.