[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
On Jun 29, 2005, at 2:24 AM, Donny Kurniawan wrote:
Greg & Nathan
So basically, we make the runtime model and the debug model the
same?
The two models will share this functionality. Runtime is IPProcess
and up (nodes, machines, etc.) and debug is IPProcess down (threads,
stack frames, etc).
We (Clement and I) are trying to merge our stuff together, but seems
that we are unclear about some things....
1. After the user selects the preferred run time (or monitoring
system) in the preference page.... what happened when the user clicks
the "run" button ???
I do assume that the ParallelLaunchConfigurationDelegate will call
execSimulatedMS() or execORTEMS() based on the chosen monitoring
system....
(footnote: well, currently it's not like that, it just calls execMI
().....)
But, am I correct to assume this????
A runtime system is composed of a monitoring system (MS) and a
control system (CS). The monitoring system observes running
processes, the state of the cluster(s), how many nodes exist on the
machines you know about, etc. The control system is responsible for
starting jobs, terminating jobs, and other related 'control' issues.
The idea is that we may have MPICH as the control system and
something like Supermon or Ganglia as the monitoring system. In the
case of OMPI, both the MS and CS are handled by OMPI (or will be in
time).
When a user selects an MS from the preferences page it causes the
Model Manager to refresh the model based on this new MS. This part
has nothing to do at all with the running of a job, it's only the
monitoring portion. The execORTEMS() and execSimulatedMS() are only
called when the MS is refreshed. All this does is setup the model
internally in ModelManager.java.
When a user clicks on 'run' or 'debug' it currently calls execMI() -
a leftover name from the mpictrl days. This method is being renamed
ModelManager.run(... same args). The code as it is right now calls
the run() method on an IRuntimeModel that the ModelManager has
instantiated. This IRuntimeModel is currently the merger of the MS
and CS. In the next day or so IRuntimeModel will be broken into a
ControlSystemModel and a MonitoringSystemModel. The complexity right
now is how to handle this with OMPI because it drives both the CS and
MS - but I'll work that out.
2. What happened when the user clicks the "debug" button???
Basically... how to make the debug model and the runtime model the
same.....
This calls ParallelLaunchConfigurationDelegate.launch(configuration,
mode, launch, monitor). This same method is called when you click the
"run" button, the difference being that the mode argument is either
the string "run" or "debug". That's the only way to distinguish
between the two. It's then up to the launch method to decide how to
start the process under debug control, or not.
3. Why does ParallelLaunchConfigurationDelegate call execMI??
Looking at ParallelLaunchConfigurationDelegate.java (before my stuff
was added).... it doesn't call execSimulatedMS() nor execORTEMS()....
It calls IModelManager.execMI(...) because it's a left-over name from
the 'mpictrl' days, but this same method will be renamed to
IModelManager.run(...). The reason it doesn't call the MS()
functions in the IModelManager() is that they are private and the
Model Manager refreshes them once
IModelManager.refreshMonitoringSystem(int ID) is called. This is
only called when a Monitoring System changes (notice, not a control
system since a 'run' is a control operation, not a monitoring
operation). The MS changes when the user selects it from the
Preferences.
The IProcess is part of the platform debug model, does
ptp.core.IPProcess extend debug.core.model.IProcess ?
Not currently. But it may need to if necessary.
4. Just wondering why there is no java.lang.Process in
org.eclipse.ptp.internal.core.PProcess ??? Is it because it's designed
that way (i.e. the actual java.lang.Process lives in remote
machines)???
We do need java.lang.Process to be given to DebugPlugin (to register
it in the debug view).... Of course... we can always fool it by
passing a wrapper to java.lang.Process (without the actual operating
system process))
The parallel runtime support doesn't really need to have a
java.lang.Process, since processes are never started with Runtime.exec
() (it's always handled by the CS) and there is no runtime support in
the Eclipse platform that is needed by the parallel runtime system.
That's why we use PProcess, which is used to represent a (possibly
remote) parallel process. All the information the parallel runtime
needs is contained in this class.
The debugger is a different situation, however, since we want to use
platform and CDT debug functionality even though the process is a
PProcess. I think what you'll have to do is create a dummy Process
and associate this with a PProcess. Then whenever the (platform/CDT)
debugger needs a Process you can pass one to it.
I notice that there's code in
ParallelLaunchConfigurationDelegate.launch() that creates a debugger
session and then processes and targets. You need to think through
very carefully if this is how it should work.
It would seem to me that you are going to want the ModelManager
control system to launch the program under external debugger control,
populate the runtime model with PProcess's, then hand control to your
debug code to instantiate the debugger session (which will create
dummy Process's as necessary). I don't think your (simulator) debug
code should be creating the processes used by the model, but it
should provide simulated call stacks and events.
Greg
