RE: On PATH_MAX

[Christopher Nelson]

> At Thu, 3 Nov 2005 11:47:02 -0700,
> "Christopher Nelson" <address@hidden> wrote:
> > 
> > > At Thu, 3 Nov 2005 11:21:17 -0700,
> > > "Christopher Nelson" <address@hidden> wrote:
> > > > Sure, but in practice how does this work?
> > > 
> > > In practice it works by first defining what your system 
> looks like, 
> > > and then finding out what the constraints are.
> > > 
> > > The problems you describe stem from the fact that you 
> have a service 
> > > that is used by multiple users concurrently, and which 
> expends some 
> > > of its own resources in handling those messages.
> > 
> > Actually, I didn't mean that at all.  Say thread A allocates 4gb of 
> > memory.  Say it then shares that memory with thread B.
> 
> What's the relationship between thread A and B?  There must 
> be a reason for A to share the memory with B.  B must _allow_ 
> the memory to be shared with A.  Why is the memory mapped, 
> and not copied?
> 
> Unless you define the relationship between A and B, you can 
> not derive anything about possible operations.

I was choosing the least memory-intensive operation.  If you copy it
then you double the amount of memory in use, which exacerbates the
problem.  I don't see how their relationship really matters.  Somehow A
has a capability that lets it talk to B.  Neither thread has any
authority *over* each other, but B provides a service.  The problem
exists even if B provides no service to any other thread, because memory
and processor space are shared resources.
 
> > Thread B cannot
> > do any meaningful work on that memory until it is mapped into it's 
> > address space.  Thread B *must* use some of it's own 
> resources (if you 
> > consider space in your address space a resource) in order to do any 
> > useful work on that information.
> 
> This is true, but it becomes a moot point if B and A use 
> exactly the same resources, for example because B was 
> instantiated by A.
> 
> Without knowing more about A and B, we can't tell if that is 
> a problem or not.

A and B always use the same resource in this instance.  Even if they are
in their own address spaces, what they both use is memory.  A has
allocated it and is presenting it to B in some way that allows B to use
it.  Whether a map, grant, or copy, when presenting it all at once the
problem remains the same.

> > Lol. I'm not sure exactly what you're saying, but I *think* that I 
> > agree with you. :-D  I don't so much mean that the kernel should 
> > impose it's own idea about how much it's going to transfer, 
> but rather 
> > that it provide a mechanism which allows the receiver to 
> say how much 
> > it wants to receive.  The receiver should not be *forced* to accept 
> > what it is given.
> 
> I agree with the last sentence.  But what you say before is 
> not true in general.  The kernel must impose its own limit on 
> a message size as well.  If you need/want to exceed that 
> limit, then you have to implement higher-level protocols, 
> which of course add their own problems.

The kernel may impose a limit on how much it will transfer between two
threads in a given amount of time, but I don't see how it follows that
it must limit how much it copies in total.  Are you saying that you wish
the copy/map/grant operation to be an ACID operation with no state side
effects, such that the kernel guarantees that it will copy X bytes, and
that those bytes will either be entirely copied or not copied at all?
If so, then you cannot have arbitrary sized string transfers and still
make that guarantee?  

-={C}=-