On Mar 14, 2014, at 6:37 PM, Greg Clayton <[email protected]> wrote:
> On Mar 14, 2014, at 1:58 PM, Kuba Ober <[email protected]> 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 _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
