Process Management (was: Re: Reliability of RPC services)

[Marcus Brinkmann]

At Thu, 27 Apr 2006 20:40:50 +0200,
Filip Brcic <address@hidden> wrote:
> 
> Дана Thursday 27 April 2006 15:24, Michal Suchanek је написао(ла):
> > On 4/27/06, Pierre THIERRY <address@hidden> wrote:
> > > Scribit Michal Suchanek dies 25/04/2006 hora 11:54:
> > > > Because of encapsulation I should not be able to kill the plugin
> > > > separately from outside, and I do not need anyway. The browser either
> > > > knows it has killed the plugin or is killed as well. No problem.
> > >
> > > Why should it be a nothing or all case? First, I'm not so sure it would
> > > break encapsulation that much to be able to kill the plugin from
> > > outside. Or it breaks it, but it is desirable anyway.
> >
> > How do you do that? If the plugin is started by the browser the
> > storage and cpu time is supplied by it. No other process needs to know
> > that the plugin was started. If you do not know it is running you
> > cannot killl it.
> 
> What about for example java plugin for some web-browser? If the browser 
> doesn't have an jre compiled into itself (I am not aware of any such 
> browser), it must start the java process one way or another. Therefore, if I 
> start some java applet and run "killall -9 java" in console, it sure will 
> kill the plugin. If you want to hide the processes from the "ps ax", strange 
> things might happen. For example, on Linux you could have just one process - 
> init.

Michal is right, the defining relationship between processes is the
parent-child relationship.  Because all resources to create a process
are decentralized, the parent of a process does not need to negotiate
the creation of the child with its own parent.  There is not
necessarily a central repository of all processes in the system, or of
a user.

So, no, killall -9 java will not kill the jvm started by the browser,
unless the browser cooperates.

Instead, every process will know about its child processes.  These
child processes have local job numbers (not global process IDs)
similar to bash's %n.  Because the resources are distributed
hierarchically, forcibly killing a job will kill all its descendants
as well.  This is the right thing to do.

So, how _can_ you kill the java vm if it is abnormally behaving?  For
this, you need the support of the browser.  There can in principle be
two ways:

(1) The browser can register its child processes with the shell
    (either directly or via its own parent, recursively).

(2) The shell can inquire the browser about its child processes and
    also to kill them.

Both solutions are roughly equivalent.  The second solution increases
locality, though, so it probably scales better and should probably be
preferred.  However, there are similar resource accounting problems in
both scenarios: In the first scenario, there will be a (user-) global
instance that keeps track of all processes, in the second case, the
list of all processes will be created dynamically when you attempt
to list them (ie, with ps, or pstree).

I think the second case is probably easier to define and handle.  (If
the response takes too long, you timeout.  If the response is too big,
you truncate the output and only provide a partial result.  Note that
this fits quite nicely with conventional tree-displaying widgets,
where you can expand the tree manually if you are interested in more
details).

So, to make this more specific, one hypothetical scenario could be
this:

$ pstree
1 calendar
2 browser
2/1 java
...

and then:

$ kill 2/1  # Kill first job of second job.

Which sends a message to job 2 (browser) asking it to kill job 1
(java).

Thanks,
Marcus