[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reliability of RPC services
From: |
Filip Brcic |
Subject: |
Re: Reliability of RPC services |
Date: |
Thu, 27 Apr 2006 20:40:50 +0200 |
User-agent: |
KMail/1.9.1 |
Дана 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.
> > On any current OS, if the plugin is a separate process, it will be
> > killable (if the browser would recover is another story).
> >
> > And if you want to preserve encapsulation, why not let the user kill the
> > plugin in the browser. If a plugin doesn't show anything or show
>
> That's what I am talking about. 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 might make the browser UI more complex. But, there is one problem. The
browser is third party, and I don't think that that party will be willing to
add more options to the browser especially for use on GNU/Hurd(NG). IMHO, the
browser must rely on the system to kill the plugin and notify the browser
about it. How it would be done is another question (kill the plugin =
watchdog or user, notify = some error in return on accessing the plugin).
--
Filip Brcic <address@hidden>
WWWeb: http://purl.org/NET/brcha/home/
Jabber: address@hidden
Jabber: address@hidden
Jabber: address@hidden
ICQ# 40994923
Yahoo! brcha
MSN: address@hidden
pgpF1BqqFAmEA.pgp
Description: PGP signature
- Correctness (was: Re: Reliability of RPC services), (continued)
- Correctness (was: Re: Reliability of RPC services), olafBuddenhagen, 2006/04/26
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/25
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/25
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/26
- Re: Reliability of RPC services, Pierre THIERRY, 2006/04/27
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/27
- Re: Reliability of RPC services,
Filip Brcic <=
- Process Management (was: Re: Reliability of RPC services), Marcus Brinkmann, 2006/04/27
- Re: Process Management (was: Re: Reliability of RPC services), Jonathan S. Shapiro, 2006/04/27
- Re: Process Management (was: Re: Reliability of RPC services), Marcus Brinkmann, 2006/04/27
- Escaping it's parents (was Re: Process Management (was: Re: Reliability of RPC services)), Pierre THIERRY, 2006/04/27
- Re: Escaping it's parents (was Re: Process Management (was: Re: Reliability of RPC services)), Marcus Brinkmann, 2006/04/27
- Child killing UI (was Re: Reliability of RPC services), Pierre THIERRY, 2006/04/27
- Re: Child killing UI (was Re: Reliability of RPC services), Marcus Brinkmann, 2006/04/27
- Re: Child killing UI (was Re: Reliability of RPC services), Pierre THIERRY, 2006/04/27
- Re: Child killing UI (was Re: Reliability of RPC services), Marcus Brinkmann, 2006/04/27
- Re: Child killing UI (was Re: Reliability of RPC services), Pierre THIERRY, 2006/04/28