================
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/
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
