On Mon, Jul 7, 2008 at 11:45 AM, erik quanstrom <quanstro@coraid.com> wrote:

i'm assuming by "core file" you don't mean executable.
plan 9 already keeps an executable cache.

A Lisp core file can be equated to a specially formatted executable. The Lisp environment is sort of a loader for these. When people distribute lisp applications, they give you a core file, and it doesn't "run on it's own" without the Lisp runtime loading it. The same goes for some Scheme implementations as well (with the notable exception of Gambit Scheme which has a C library runtime, and can build standalone binaries as well as more C code, and it's not even GNU specific C thank god)

Remember code is data and data is code in Lisp land.

> Presumably the reads are cached?

reads are not cached. read on plan 9 is syncronous.
there is no block cache.

> Even so, there will the cost of copying to the segment. Or can
> one create multiple text and data segments in some way so
> that stuff will be paged in as necessary? Also, if a shared
> segment is created won't the forked processes be able to
> modify this segment? Ideally one would like a private copy
> for each child. Is segattach + read the best (only?) way to
> do this?

why wouldn't you use ramfs?

- erik