Re: On PATH_MAX

[Marcus Brinkmann]

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.

> 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.

> 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.

Thanks,
Marcus