[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: On PATH_MAX
RE: On PATH_MAX
Tue, 8 Nov 2005 08:51:09 -0700
> On Mon, Nov 07, 2005 at 09:57:49AM -0700, Christopher Nelson wrote:
> > > On Mon, 2005-11-07 at 09:32 -0700, Christopher Nelson wrote:
> > > It is possible to design protocols that are flawed in the
> way that
> > > you describe, but they are self-evidently broken.
> > Yes, this is my point exactly. Requiring support for
> arbitrary sized
> > string transfers is a broken mechanism. I don't feel that
> it's a good
> > idea to expect a server to simply accept whatever you throw
> at it. Up
> > to and including bazillion-character-long paths. The example was
> > designed to highlight that, and it seems to have
> successfully done so.
> Not exactly. If a server wants to support arbitrary long
> paths, it's not going to map the whole thing into its address
> space. It'll accept a container capability and map parts of
> it in, unmapping other parts of it.
What mechanism allows it to map *parts* of a single transfer in?
> The problem that remains is that the operation can take very
> long. If you have a 4GB filename (or the maximum 64 bit
> value), the server will have a lot of work checking it. Then
> again, it's doing that on your provided scheduling time, so
> that should be no problem, as long as other requests are not
> delayed by it.
Sure, except that while it's working on YOUR request, it's not
processing anyone else's request.
RE: On PATH_MAX, Christopher Nelson, 2005/11/08
- RE: On PATH_MAX, (continued)
- RE: On PATH_MAX, Christopher Nelson, 2005/11/08