l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Child killing UI (was Re: Reliability of RPC services)


From: Pierre THIERRY
Subject: Child killing UI (was Re: Reliability of RPC services)
Date: Fri, 28 Apr 2006 00:34:57 +0200
User-agent: Mutt/1.5.11+cvs20060403

Scribit Michal Suchanek dies 27/04/2006 hora 15:24:
> > 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.

Yeah, but as I said, in some systems that encapsulation is obviously
broken. POSIX seems a fine example, where processes are globally
registered. When I ask a tree view of the processes, I can view what
processes have be spawn by my browser. And slay them without mercy.

> The plugin is started and exclusively used by the browser so there is
> no problem with providing an option to kill it from the browser.
> Except it might make the browser user interface more complex.

It would make the interface more complex, but the life of the user
easier. Only the average computer-savvy knows how to kill a process from
outside the application that spawned it, either in the shell or with
some WM dialog.

A menu that would have 'kill the X plugin', and/or maybe a watchdog that
barks at the user when something goes wrong, would definitely help the
user keeping its environment in a safe and working state with autonomy.

Ergonomically,
Nowhere man
-- 
address@hidden
OpenPGP 0xD9D50D8A

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]