Re: Druid Debug Session Info

[Phil Muldoon <pmuldoon at redhat dot com>]

Sorry date on my laptop was fubar. Fixed now (hopefully).

Sami Wagiaalla wrote:
> Okay so the main question is what does the user want
> to see when the reopen an old debug session, that will
> tell us what data a debugs session needs to contain/save:
>
> As a frysk developer I want my  fryskDebug session  to
> do the following. Watch for every  instance of  my development
> frysk, add a terminating observer to it, and perhaps add some
> tag-sets.

What about adding other observers (as in the add observers step)? This 
turns out to be the the thorniest storage issue. How do we store them? 
How we do we relate them to the processes that we choose?
> This is a summary after reading your email phil:
>
> class DebugSession{
>
>    executable path(s)
>
>        running instances (if the user chooses to debug an executable
>                                      we run an instance and that will
>        satisfy this
>                                      requirement)
>
>            observers (to be applied once we have running instances)
>            tag-sets( ditto )
I sort of see a different scenario if the user chooses to debug an 
already running executable from the first main page of the druid. At 
that point, the session would become almost insignificant? IE we would 
pass the process off to the source window manager and that would attach. 
Would we even show the monitor at that point?  Though you note we should 
have a session even if we just want to debug an already running 
executable, I guess the session concept is valid. It would have to be a 
temporary non-persistent session.  We need to expand here a bit on the 
work-flow. ;)  Though as you mention below that a session should store 
all other metadata associated beyond the druid (ie what bp's the user 
set, and so on), then I can see a session being needed at all points.
> }
>
> > As I finish off the Druid GUI, next step is to agree on what a 
> > Session is and what a Session Manager does and migrate this data into 
> > a session object. So that both the Session Class and the 
> > SessionManager can be the broker between the Druid and the Monitor 
> > and form a contract of what one provides, and what one expects.
> Session Manager intanciates, saves, loads Sessions, keeps
> track of current Sessions. This will fall out once we decide
> what sessions are.

Session Manager should call the Session object to save itself right? It 
would load all currernly available sessions on startup and manage them, 
agreed.

> > A Session is the collection of data that the Frysk Debug Session 
> > Druid gathered from the user. So:
> A session is the information the user wants to focus on, and have 
> saved once
> the restart frysk... I am sorry I am getting a bit "Desktopy" on you 
> phil :P
Same concept, different flavor I guess. I think we are saying the same 
things ;)

> > - A list of chosen process groups:
> >
> > ie: bash, gnome-terminal, httpd, and so on.  This is what the user 
> > chooses at the beginning of the druid. These are groups, and any 
> > process matching that name description should be matched and filtered 
> > in the ProcWiseDataModel.java
> Yup
> > From that list above:
> >
> > On page 2 of the druid, the user defines any of those process groups 
> > to notify on abnormal termination. This would trigger a default 
> > action (stop and send message to user?). so:
> >
> > - a sub-list of process groups that on termination, trigger an action
> >
> > On page 3, the user defines any tag sets to apply to those process 
> > groups. The tag sets are sourced from the Tag Manager via a filter. so:
> >
> > - a list of tagsets per process group to apply on startup
> >
> > On page 4,  for each process group chosen, what observers (if any, or 
> > many) to apply at start-up.  so:
> >
> > - a list of observers to apply per process group on startup.
> >
> > So as an example
> >
> > bash
> >  - notify on termination
> >  - apply bash_foo_debug_tagset, bash_bar_debug_tagset
> >  - apply forkAndExecCustomObserver, syscall, taskTermination
> > httpd
> >  - do not notify on termination
> >  - do not apply any tagsets
> >  - apply fork, exec observer
> > gnome-terminal
> >  - do not notify on termination
> >  - do not apply any tagsets
> >  - do not apply any observers
> >
> > So we have this data in the druid. Next step it to create a 
> > DebugProcess class that can encapsulate that data (one DebugProcess 
> > class per Process Group).
> >
> > class DebugProcess
> >
> >    ArrayList processGroups;
> >    (how do we list the observers, tagsets and exit flags)
> >    (seperate groups, or a hash of some kind?)
> >    ...
> >    ...
> Perhaps debug process should be inside a DebugSession
> so one DebugSession->Many DebugProcessies -> many observer/tags

Can you elaborate a bit more here? Are you talking of nesting sessions?
> > So I'll kick this open on how we remember what observers, tagsets, 
> > and termination events to apply to each process group. Also, should 
> > we implement the SaveableXXX interface we use in custom observers to 
> > make Sessions self saving/loading?
> IMO this worked well for CustomObservers, and it applies here.

Excellent, so we'll use that then.
> > How are sessions validated. Do they have an expiry. Ideas? ;)
> I envision sessions to save alot more informations, such as break
> points, watched variables, etc. how is that information 
> validated/expired... I donno :)
I totally agree with this, in the future. For now lets limit SessionData 
to the Druid - at least for this initial exercise (we can always extend 
it later). The storing of BP's in a session is pretty nice idea though. 
Hmmm ;)

Regards

Phil