[Lldb-commits] [PATCH] Fix handling of CommandInterpreter's events in lldb-mi

[Jim Ingham]

================
Comment at: tools/lldb-mi/MICmnLLDBDebugger.cpp:300
@@ -299,2 +299,3 @@
     bOk = bOk && RegisterForEvent(strDbgId, CMIUtilString(lldb::SBCommandInterpreter::GetBroadcasterClass()), eventMask);
+    m_lldbDebugger.GetCommandInterpreter().GetBroadcaster().CheckInWithManager();
 
----------------
ki.stfu wrote:
> clayborg wrote:
> > ki.stfu wrote:
> > > abidh wrote:
> > > > Why we have to do this for command interpreter? 
> > > Because CommandInterpreter object already has been created in contrast to Target/Thread/Process.
> > You shouldn't have to do this, it is being done in the lldb_private::CommandInterpreter::CommandInterpreter(). How did you manage to not contract a CommandInterpreter and yet you are able to listen to events from it?
> >RE: You shouldn't have to do this, it is being done in the lldb_private::CommandInterpreter::CommandInterpreter().
> But I have a problem:
> # CMICmnLLDBDebugger::InitSBListener() registers events (which are needed for lldb-mi) using the SBListener::StartListeningForEventClass().
> # SBListener::StartListeningForEventClass() is used for classes that weren't created (otherwise the SBBroadcast::CheckInWithManager() should be called).
> # In this situation, we register events (using SBListener::StartListeningForEventClass()) for already created class SBCommandInterpreter. I can't register events before this class is created because it is done simultaneously with SBDebugger (which is used in SBListener::StartListeningForEventClass()).
> 
> I assume we can use SBListener::StartListeningForEventClass() for SBTarget/SBProcess/SBThread and SBListener::StartListeningForEvents() for SBCommandInterpreter but I'm not sure that it's right solution.
> 
> Do we have any restrictions to use SBListener::StartListeningForEventClass()?
> 
> >RE: How did you manage to not contract a CommandInterpreter and yet you are able to listen to events from it?
> Previously lldb-mi ignored all CommandInterpreter's events.
There are two restrictions for SBListener::StartListeningForEventClass.  The first is that the debugger you pass into the call must be a valid debugger.  Otherwise the StartListeningForEventClass will return 0, meaning you got signed up for no event bits.  Although lldb supports multiple debuggers, it does not support coordination among debuggers, you can't have a listener that listens to all classes of events for all debuggers.  So this restriction is necessary.

The other restriction in the BroadcasterManager is that we only let one listener sign up for events of a given class/bit pair.  So if somebody else had grabbed that bit for that event already, then you wouldn't get it.  Again, you should be able to tell from the return value to StartListeningForEventClass whether you got the bits you requested or not (the call will return 0 if there are no available bits.)

If the problem is some other listener already acquired the event spec you are asking for, we can relax the requirement that event class listeners be unique.  We went back & forth about whether we wanted to support multiple listeners for some events or not.  Looks like I did the BroadcasterManager stuff at the point where we wanted one Listener per Broadcaster/EventBit.  For the most part,  however, Events can really be "broadcast" rather than go to a single listener without causing problems.  So I have no problem relaxing this restriction for listening by event class.

The exception to this is that the Process broadcaster really needs to have only one StateChanged listener.  When you create a process you have to give it the Listener that is going to drive it.  So we don't want people to sign up for Process events by class.  So if the problem is not allowing multiple listeners per class, we can change BroadcasterManager::RegisterListenerForEvents to not filter the request against the extant listeners.  But then we should add a call to the BroadcasterManager to say which BroadcasterEventSpec's can't be listened for by class - and make the Debugger outlaw listening to Process events by class.

http://reviews.llvm.org/D8382

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/