Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!purdue!tut.cis.ohio-state.edu!unmvax!deimos.cis.ksu.edu!rutgers!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.wizards
Subject: Re: is this wise?
Message-ID: <8427@chinet.chi.il.us>
Date: 10 May 89 17:08:23 GMT
References: <9321@alice.UUCP> <54270@uunet.UU.NET>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 34

In article <54270@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes:

>Do they really spend 3 system calls to get the clock time
>(open,read,close) or do they have some other scheme?

Do you open /dev/tty and close it every time you want to output a
character?

>It seems like a hell of a lot of work to find out something simple
>like the time of day. (Or am I still stuck in the past when
>performance mattered?)


With a scheme of providing an fd per resource, more standard fd's
could be defined and assumed to be inherited so the open/close
calls wouldn't have to be made.  Even without that, a process can
do the open() once and hang on to the fd.  The advantage is that
the connection is made at run-time and the actual service provided
could be modified by the requestor (by asking for a different named
resource) or the server (by re-mapping the request, perhaps to a
resource provided by another machine as in RFS files).

>How far does plan 9 take the clock as a file analogy? Do they
reset the clock if root does a seek on it?

A write would be the obvious thing.

>What about things like getpid or getppid?

Again, this would be great for networks - a single PID server could
make sure that pids where unique and allow them to be used in
lockfiles and such. 

Les Mikesell