l4-hurd
[Top][All Lists]
Advanced

[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}=-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]