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

[Kuba Ober]

On Mar 14, 2014, at 6:37 PM, Greg Clayton <gclayton at apple.com> wrote:

> On Mar 14, 2014, at 1:58 PM, Kuba Ober <kuba at mareimbrium.org> wrote:
> 
>> […]
>> A simple async-ification would:
>> 
>> 1. Add an optional SBAsync & async = SBAsync::Null() parameter at the end of the parameter
>> list. This class would have fields that determine the following:
>> - that the command is to execute asynchronously,
>> - a client-provided command ID to pass into the result,
>> - the ordering behavior (if any),
>> - whether the result is to be provided via an event broadcast (and what is the listener).
>> 
>> 2. Amend SBError to provide an InProgress() state, and a way to get the copy of SBAsync
>> instance that was used to start the command (to correlate with command ID etc),
>> and a way of getting whatever data was requested. Such result would be asynchronously
>> updated as the command progresses, allowing to poll progress. 
>> 
>> Some APIs return an error code instead of using SBError, so those would need to be amended,
>> to do both. For example
>> SBProcess::GetProcessId() -> SBProcess::GetProcessId(SBError & err = SBError());
>> 
>> Does this make any sense?
> 
> 
> I don't think it makes sense to build into our public API. I could see this as an add on Library and uses our public API and implements things on top of that API, but not as an integral part of the API itself.
> 
> So I would challenge you with this: build something on top of the API that implements your vision with the async calls. Make some code that uses your new APIs. Check in your new parts into trunk/tools/asynclib and we can all check it out and we can go from there?
> 
> A few reasons:
> 1 - the public API is all vended to Python and should make sense for use as python objects and be useful for programs (GUIs included) to use a framework for accessing and controlling debuggers and symbolicators
> 2 - keep the public API simple for all languages (python and C++ currently)

I think that what I propose not only doesn’t break existing users, but requires zero changes
even to existing generated bindings code. Basically you can ignore the new parameters or methods,
and everything should still work as-is, including stale swig-generated code if you decided to keep such
around.

So, while it’s not a binary-compatible change, it’d be a 100% source-compatible change from
all points of view.

The problem with the current design is that there’s no way to make it truly asynchronous via wrappers,
since as far as I can tell, locks are held across pipe and network reads/writes.

I’ll do a proof-of-concept, but any wrappers come at a cost of extra thread(s) to wrap the
implicitly synchronous, blocking API. Internally, essentially anything that runs on the local
host and doesn’t use an external process can be kept blocking. Anything that uses an external
process or connects via the network, or via a serial connection, needs to be asynchronous.

Cheers, Kuba