From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <64b8583f7ed7ee9d33cd51f8ea360d02@quanstro.net>
Date: Fri,  9 Jun 2006 17:35:09 -0500
From: quanstro@quanstro.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] gcc on plan9
In-Reply-To: <8ccc8ba40606091517h41cc3ae4qc8952c39ea1cbd4b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 658a58b0-ead1-11e9-9d60-3106f5b1d025

is this also true for everything running on the same machine?
i'd be interested in what the performance difference is in that case.

does the kernel or a userlevel fs serve /cmd?

- erik

On Fri Jun  9 17:18:40 CDT 2006, nemo@lsub.org wrote:
> Without caching, a lot. When you cache the file nearby /cmd, and
> you avoid copying if you can do so, it=C2=B4s not so slow (don=C2=B4t h=
ave numbers
> right now, sorry).
>=20
> On 6/10/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> > it is interesting that plan 9 could be rearranged as a classic =C2=B5=
kernel, using
> > 9p for message passing.  a process server could do just that.
> > before you kill me, note the difference between "interesting" and "be=
tter." =E2=98=BA
> >
> > how much slower is an exec over /cmd than via fork(2)/exec(2)?
> >
> > - erik
> >
> > On Fri Jun  9 16:59:40 CDT 2006, nemo@lsub.org wrote:
> > > Well, in Plan B we made an experimental /cmd, where processes
> > > were files in the sense that mkdir created one process, cp was used
> > > to supply the binary and the like. It did work, but it seemed more
> > > convenient to use the distributed plumbing to deliver cmd execution
> > > requests, and then, ox, the shell underlying omero, is in charge of
> > > executing the commands. Now we are back into /proc.