l4-hurd
[Top][All Lists]
Advanced

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

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


From: Bas Wijnen
Subject: Re: Child killing UI (was Re: Reliability of RPC services)
Date: Fri, 28 Apr 2006 11:34:30 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Fri, Apr 28, 2006 at 12:34:57AM +0200, Pierre THIERRY wrote:
> > > 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.

So you are suggesting we should build a broken system, because others have
done so as well?  I don't think I like that approach. ;-)

> POSIX seems a fine example, where processes are globally registered.

Yes, and we will allow this for POSIX applications, which link to the POSIX
library.  This library will provide all the interfaces which are needed to
allow listing and killing of its children.  But programs which are written for
HurdNG only provide those interfaces if they actually want them.  They can
also choose to keep their list of processes secret.

For example, I think it is likely that a user's session manager will not allow
listing of its processes (at least not to anyone except the user).  That means
that others (including the system administrator) cannot see what programs the
user is running.  And that's a good thing, privacy-wise.

> 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.

You still can if the browser cooperates.  And it probably will.

> > 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.

Only if the browser does this through a graphical means.  At first, I think it
is fine to have only a capability interface for it.  Especially for POSIX
programs, which aren't likely to be changed by upstream.

> 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.

Yes, I think it would be a good idea.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


reply via email to

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