RE: On PATH_MAX

[Christopher Nelson]

> Bas Wijnen wrote:
> > On Wed, Nov 09, 2005 at 01:38:20PM +0100, ness wrote:
> > 
> >>>>IMO giving no reasonable specification of latency in a case where 
> >>>>the process supplies a real long filename is not a 
> problem.  If the 
> >>>>process cannot handle it, it can limit the size itself.
> >>>
> >>>No no. The file system can no longer make any specification of 
> >>>latency for *any* file, because the act of locating 
> *other* files may 
> >>>require a name comparison on an arbitrarily long name 
> along the way.
> >>
> >>Why shouldn't the thread of execution and scheduling time 
> be provided 
> >>by the caller, too?
> > 
> > 
> > I think the idea is that it does.  The problem is that I 
> call a file 
> > system server and ask for a list of files, and I never get a reply 
> > because a file name is too long.
> > 
> > I still think this can be fixed by limiting the name to some 
> > client-specified size though.  I just realised that the 
> client should 
> > also communicate this size to the server, so it doesn't attempt to 
> > transfer more (taking more time than needed).
> > 
> > Thanks,
> > Bas
> > 
> The problem Jonathan pointed out is that *others* will delay. 
> This is not the case, as the server will be multithreaded.

Actually, since there's no latency guarantee, no single thread can
provide any guarantee regarding how long an operation will take.  Its
not just others, since some programs require some sort of guarantee
regarding latency to function correctly. Ie. Audio/video players, etc.

-={C}=-