[lldb-dev] Async mode and listeners

[snare]

Hi Greg, 

Thanks for your feedback.

> So I would suggest not using "ci.HandleCommand()" if you can. There are better API calls for this that will return your the objects that you need.

I realise this, but the only reason I’m writing code that instantiates the debugger and controls this itself is because I cannot get the callbacks I need from the regular LLDB CLI driver (previous discussion here: http://lists.cs.uiuc.edu/pipermail/lldb-dev/2013-October/002554.html)

I would *really* rather not have to reimplement the entire CLI myself, I just want some additional callbacks on top of LLDB’s CLI - which is why I’m using SBCommandInterpreter in the contrived example.

> Why is it blocking? You should look at a sample or interrupt with a debugger and see why.

OK I will look.

> You should probably let the debugger handle everything including the command interpreter. Just call:
> 
> auto_handle_events = True
> spawn_thread = False
> 
> debugger.RunCommandInterpreter (auto_handle_events, spawn_thread)
> 
> This will run everything for you just like the command line LLDB. If spawn_thread is false, then it will block until the command interpreter is exited, else if spawn_thread is true, the command interpreter will be run on another thread and it will return allowing you to do other things.
> 
> There currently isn't an option to just say "handle the events for me". The built in one exposed in SBDebugger::RunCommandInterpreter(...) will always print messages out to the stdout/stderr that you gave to the debugger:
> 
>    void
>    SBDebugger::SetInputFileHandle (FILE *f, bool transfer_ownership);
> 
>    void
>    SBDebugger::SetOutputFileHandle (FILE *f, bool transfer_ownership);
> 
>    void
>    SBDebugger::SetErrorFileHandle (FILE *f, bool transfer_ownership);

RunCommandInterpreter() sounds like it may do what I want it to do, I will give it a try.

> So if you don't want it to do that and provide the feedback just like the command line tool, then you should be running your own event loop.

Yeah this is what I’m trying to avoid, as above.

Thanks,
Loukas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140719/b00e6262/attachment.html>