This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Event notification (was Re: GDB/MI lawyer for Thread Creation)


> 
> 
> > I went digging in the old email exchanges with kseitz ....
> > And yes this is what I'm looking for
> > 
> > one nitpicking:
> > 
> > - the event notifications mechanism seem to be for side effects, for example
> > setting a breakpoint via CLI, notification is sent informing of the side effect.
> > Or assigning statements having side effects.
> > 
> >   It does not seem to address "pure" async event.  Threads creation/destruction,
> > and loading of shared libs are two examples that spring to mind about the need
> > of notification when the inferior is still running.
> > 
> >   It those cases, I would say that sending an OOB instead of async-notify is more
> > appropriate.
> 
> Hmm, makes sense - a real rationale.  Anyone else have comments?
> 
> Want to re-word the MI doco so this is clearer?
> 

heu .... being native french speaking... mais bien sure!!!
(evil laughter here ...)

> > Questions:
> > Will kseitz_interps-20020528-branch be merge to the main trunk?
> > Any ETA ?
> 
> The branch contains a lot of stuff, but importantly prototypes for two 
> new features:
> 	- interps command
> 	- breakpoint events
> The interps feature is now implemented in the mainline.  The breakpoint 
> stuff has't been done.   One missing bit of the framework needed for 
> that feature - observer.[hc] - was recently added by Joel though.
> 

Observers ... looking trough the code ......
Was the observer pattern also intended for other notifications then stop.
Like
	observer_attach_thread_creation()
	observer_attach_shared_loaded()

etc ...

Or it is the wrong approach?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]