address@hidden: Re: address@hidden: hurd-paper again]]

[Jeff Bailey]

This is a nice explanation from Gordon.

----- Forwarded message from Gordon Matzigkeit <address@hidden> -----

X-MailHub: mail.nisa.net
To: address@hidden
Cc: address@hidden, address@hidden
Subject: Re: address@hidden: hurd-paper again]
X-Attribution:  Gord
From: Gordon Matzigkeit <address@hidden>
Date: 12 May 2001 13:48:10 -0600
In-Reply-To: Richard Stallman's message of "Fri, 11 May 2001 23:42:34 -0600 
(MDT)"
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
X-scanner: Scanned by Nisa EPOscan v3.01 (www.nisa.net)

>>>>>  Hurd Paper:

 HP> However, the Hurd is constructed so that the worst possible
 HP> consequence is an interruptible hang.

>>>>>  Vincent Legoll writes:

 VL> I can't clearly understand what "hangs" (and what is required to
 VL> interrupt that hang).  You meant the wrong process used as a
 VL> translator hangs and the system can recover from that situation
 VL> by interrupting (a CTRL-C / SIGINT equivalent) this process ?

No, when a client process tries to access the filesystem, it will
expect the translator to implement the filesystem protocol, and so
will wait for the translator to reply.

If the translator returns a bad reply, then the client will propagate
an error, so there is no problem.  On the other hand, if the
translator doesn't reply at all, the client will hang waiting for it.

On the Hurd, you can just interrupt the client (C-c, or some other
signal), and it will stop waiting.  On many other kernels, the client
cannot be interrupted, and will essentially prevent the client's
terminal from being used until the system is rebooted, or the
translator returns some kind of a reply.

Is that clearer?

-- 
 Gordon Matzigkeit <address@hidden>  //\ I'm a FIG (http://fig.org/)
Committed to freedom and diversity \// Be Pliant (http://fig.org/pliant/)

----- End forwarded message -----