[lldb-dev] Is there support for command queuing/asynchronicity in lldb?

[Greg Clayton]

On Mar 14, 2014, at 9:46 AM, Kuba Ober <kuba at mareimbrium.org> wrote:

> Do lldb internals support/make it possible to queue commands
> for remote debugging, and to have the results of the same
> reported asynchronously?

No, not currently.

> This is needed for good user experience on targets that
> are being debugged remotely or via JTAG and similar debugging
> dongles. Quite often such connections are slow and the
> commands can take very long to execute.
> 
> Ideally, the user or the IDE should not be expected to
> know to split long-running commands into smaller pieces/
> 
> Specifically, I’m thinking of following features:
> 
> 1. Submit a command for execution asynchronously -
> it returns right away, and the result(s) are reported lated.
> 
> 2. Get partial results from asynchronous command execution
> as it progresses. For example, during a long memory read
> it’d be nice to get periodic notifications as each “chunk”
> of data comes in.
> 
> 3. Specification of partial ordering between commands.
> The default would be to have totally ordered command execution
> as is the case right now, but sometimes this can be relaxed.
> 
> Again, think of a very long running memory dump - several
> megabytes of stuff being read, it can take dozens of seconds
> on slow dongles or slow network connections. If the user
> (or an IDE) wants, the subsequent commands can be given
> with relaxed ordering such that they don’t have to be delayed
> until the memory read finishes. Say that a user wants to change
> a register while the memory is dumped, or request a smaller
> read somewhere else that could finish much sooner.
> 
> This would provide for good interactive user experience in IDEs.
> 
> 
> Any thoughts/hints/input?

I don't believe async should be built into our API as this would really change the entire nature of the API. It would also seriously affect our Python API bindings and all existing programs that currently link the LLDB.

But that isn't to say we can add a "read/write memory in background" to our Process API. That would be really useful and it would be great to be able to cancel such an operation. So I would vote to identify these long running operations and add support for them into our public API.

So we could add something like this to SBProcess:

class SBProcess {

    typedef bool (*MemoryProgressCallback)(
	addr_t orig_addr, // Original start address for memory read/write
	addr_t orig_size, // Original size of the memory read/write
	addr_t curr_pos,  // The address that was just written used for progress
        SBError &error,   // The error for the current memory read/write
	void* baton);	  // The void * passed to the read/write memory in background call

    void
    ReadMemoryInBackground (addr_t addr, void *buf, size_t size, lldb::SBError &error, MemoryProgressCallback callback, void *baton);

    void
    WriteMemoryInBackground (addr_t addr, const void *buf, size_t size, lldb::SBError &error, MemoryProgressCallback callback, void *baton);

}

When the MemoryProgressCallback is called, it can return "true" to keep going, for "false" to cancel.

So I would vote:
1 - identify things we know are going to take a long time and make sure we have an API for common things (like long read/write memory)
2 - Use the API to build things that aren't commonly needed by everyone.

Right now, an IDE can implement the background memory read/write with progress using our public API. Just spin off another thread and break the read/write up yourself and submit smaller reads/writes. Have your other thread run your GUI and it will be able to read/write registers, etc without interrupting your memory read/write thread.

Our API is multi-threaded aware and safe, so there might not even be anything we really need to do here. Just use the existing API. The memory read/write in the background would be a nice addition to the API, so I would be happy to have this added as a nice functionality so not everyone has to code this up themselves.