Tasker



next up previous
Next: Implementation Up: Extensible Services Previous: Use in Condor

Tasker

A tasker is a PVM task that starts (execs, and is the parent of) other tasks. The tasker facility allows a secific PVM task to control the creation and execution of all tasks in the system. This could be useful when newly spawned tasks need to be under the control of some other process for debugging or performance monitoring reasons. In general, a debugger is a process that controls the execution of other processes - can read and write their memories and start and stop instruction counters. On many versions of Unix, a debugger must be the direct parent of any processes it controls. This is becoming less common with growing availability of the attachable ptrace interface.

PVM already provided a simple debugger interface: If a task is spawned (via the pvm_spawn call) with flag PvmTaskDebug set, the pvmd execs a debugger program instead of the actual task executable. The debugger arguments are the executable file and arguments for the task. The debugger can then start the task to be debugged.

The tasker interface coexists with this simple debugger interface, but is fundamentally different for two reasons: First, the tasker cannot be enabled or disabled by spawn flags, so it is always in control. Second, all tasks running under a pvmd (during the life of the tasker) may be children of a single tasker process. With PvmTaskDebug, a new debugger is necessarily started for each task.

If a tasker is registered (using pvm_reg_tasker()) with a pvmd when a DM_EXEC message is received to start new tasks, the pvmd sends a SM_STTASK message to the tasker instead of calling execv(). No SM_STTASKACK message is required, closure comes from the task reconnecting to the pvmd as usual. The pvmd doesn't get SIGCHLD signals when a tasker is in use, because it's not the parent process of tasks, so the tasker must send notification of exited tasks to the pvmd in a SM_TASKX message.

The message format is:

The tasker interface is the result of collaboration with the Paradyn group [8]. We hope that others will take advantage of it as well, to allow cleaner integration of their systems.



next up previous
Next: Implementation Up: Extensible Services Previous: Use in Condor



Jack Dongarra
Sun Dec 18 11:30:23 EST 1994