[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: On PATH_MAX
From: |
Christopher Nelson |
Subject: |
RE: On PATH_MAX |
Date: |
Tue, 8 Nov 2005 10:39:41 -0700 |
> On Tue, 2005-11-08 at 10:04 -0700, Christopher Nelson wrote:
> > > On Tue, Nov 08, 2005 at 08:51:09AM -0700, Christopher
> Nelson wrote:
> > > There is no transfer of data, there is only transfer of the
> > > container capability. This capability gives access to a set of
> > > pages, which can be mapped in or out of the address space
> when the
> > > process likes.
> >
> > You still have data transfer, even if it's only in the form
> of metadata.
> > A thread can't access any memory until it's mapped into its address
> > space. If you say that a thread must only keep a handle to the
> > metadata that defines the memory and then map it in and out
> as needed,
> > you essentially turn the operation into an
> open..read..close, and you
> > add tremendous complexity in the form of a buffering layer to map
> > pages in and out. I'm not saying its impossible, I'm
> saying its not a
> > good idea, IMHO.
>
> Actually, the metadata is shared, it isn't *nearly* as
> complex as open/read/close, and it all works just fine in
> practice in a bunch of current EROS subsystems.
Yeah... I was thinking about that after I wrote it, and I can see how
that is the case. Does the implementation simply have a user-slidable
window? Something comparable to a seek, where I can now access that
memory from byte x to x+n where n is the window size? Or is it
automated in some fashion?
-={C}=-
- Re: On PATH_MAX, (continued)
RE: On PATH_MAX, Christopher Nelson, 2005/11/08
RE: On PATH_MAX, Christopher Nelson, 2005/11/08
RE: On PATH_MAX, Christopher Nelson, 2005/11/08
RE: On PATH_MAX,
Christopher Nelson <=
RE: On PATH_MAX, Christopher Nelson, 2005/11/08
RE: On PATH_MAX, Christopher Nelson, 2005/11/08
RE: On PATH_MAX, Christopher Nelson, 2005/11/08
RE: On PATH_MAX, Christopher Nelson, 2005/11/09