Path: utzoo!utgpu!watserv1!watmath!att!rutgers!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!xylogics!merk!alliant!linus!think!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.nfs
Subject: Re: NeFS -- where is the multiplexer?
Keywords: NeFS, NFS
Message-ID: <40531@think.Think.COM>
Date: 12 Jul 90 04:26:47 GMT
References: <1086@cluster.cs.su.oz> <138584@sun.Eng.Sun.COM>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 21

In article <138584@sun.Eng.Sun.COM> brent@terra.Eng.Sun.COM (Brent Callaghan) writes:
>For the first cut at this protocol we're not proposing anything very
>radical when it comes to NeFS "processes".  Indeed, there's no process
>support at all (c.f. NeWS).  The client typically sends a request and
>blocks while the request is executed on the server.  This isn't any
>different from the RPC model that NFS uses.  A request will run just
>as long as the server wants it to i.e. until it completes or it runs
>out of resources: memory or execution quota.

I think you're answering the wrong question.  The issues isn't client
processes but *server* processes.  If a client sends an NeFS request that
runs for a long time (or worse, contains an infinite loop), the server
process will be unable to respond to other clients for the duration of that
request.  This is true with NFS as well, but NFS doesn't have any
operations that can take a long time on the server, so clients can't really
block each other out for long.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar