[lldb-dev] RFC: libtrace

[Pavel Labath via lldb-dev]

On Wed, 27 Jun 2018 at 01:14, Zachary Turner via lldb-dev
<lldb-dev at lists.llvm.org> wrote:
>
> Yes that’s what I’ve been thinking about as well.
>
> One thing I’ve been giving a lot of thought to is whether to serialize the handling of trace events.  I want to balance the “this is a library and you should be able to get it to work for you no matter what your use case is” aspect with the “you really just don’t want to go there, we know what’s best for you” aspect.  Then there’s the  fact that not all platforms behave the same, but we’d like a consistent set of expectations that makes it easy to use for everyone.
>
> So I’m leaning towards having the library serialize all tace events, because it’s a nice common denominator that every platform can implement.
>
> To be clear though, I don’t mean that if 2 processes are being traced simultaneously and A stops followed by B stopping, then the tool will necessarily block before handling  B’s stop.  I just mean that A and B’s stop handlers will be invoked on a single thread (not the threads which are tracing  A or B).
>
> So A stops, posts its stop event on the blessed thread and waits.  Then B stops and does the same thing.  A’s handler runs, for whatever reason decides it will continue later, saves off the event somewhere, then processes B’s.  Later something happens, it decides to continue A, signals A’s thread which wakes up.
>
> I think this kind of design eliminates a large class of race conditions without sacrificing any performance.
>

Does this mean that you will always have to have at least two threads
(the one doing the tracing and the one where stop handlers are
invoked)? Because if that's true, then I'm not sure I buy the
no-performance-sacrifice part. Given that with ptrace (on linux at
least, but I think that holds for some other OSs too), all debugging
operations have to happen on a specific thread, if that thread is not
the one where the core logic happens, you will have to do a lot of
ping-pong to do all the debugging operations (read/write
registers/memory, set breakpoints, etc.). Of all the use cases, the
one where this matters most may be actually yours -- I'm not sure I
understand it fully but if the goal is to have as little impact on the
traced process, then this is going to be a problem, because every
microsecond you spend context-switching between these two threads is a
microsecond when the target process is not executing. In lldb-server
we avoid these context switches (and race conditions!) by being single
threaded. It think it would be good to keep things this way by having
the new api (the lowest layers of it?) accessible in a single-threaded
manner, at least on platforms where this is possible (everything
except windows, I guess).