Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!elroy.jpl.nasa.gov!lll-winken!sun-barr!newstop!sun!terra.Eng.Sun.COM!brent
From: brent@terra.Eng.Sun.COM (Brent Callaghan)
Newsgroups: comp.protocols.nfs
Subject: Re: NeFS -- where is the multiplexer?
Keywords: NeFS, NFS
Message-ID: <138779@sun.Eng.Sun.COM>
Date: 12 Jul 90 00:39:03 GMT
Sender: news@sun.Eng.Sun.COM
Lines: 33

> Irrelevant - if I ask the server to calculate pi to a million
> decimal paces and then read a block, I should expect it to take
> a long time. The people who are in trouble are the other
> clients expecting to see the NeFS server handle the simple
> request they sent it less than a second ago.

This doesn't make sense.  If you steal CPU cycles from your
server it'll slow down client's requests not matter what 
protocol they're using to access the server's filesystem.


> >Several have suggested adding a facility that lets a request fork
> >multiple processes on the server where appropriate e.g. a search
> >of a filesystem tree.  This is a relatively rare filesystem operation.
> >The extra complexity doesn't justify itself (KISS).
> 
> Sorry but that won't do. If NeFS isn't multi-threading requests
> then it really is a totally stupid suggestion and not worth
> wasting time on.

I think you're confused here.  There's nothing to prevent
an NeFS server from being multi-threaded.  It's completely
up to the implementation.  NFS servers typically run multiple
threads via nfsd contexts.  There's nothing to stop you
having nefsd's too.  The discussion was whether multiple
threads should be visible to a NeFS request i.e. should
a request be able to "fork" itself when it arrives at the
server.
--

Made in New Zealand -->  Brent Callaghan  @ Sun Microsystems
			 uucp: sun!bcallaghan
			 phone: (415) 336 1051