Re: On PATH_MAX

[ness]

Bas Wijnen wrote:
> On Thu, Nov 10, 2005 at 01:29:21AM -0500, Jonathan S. Shapiro wrote:
>
> > > > > Why shouldn't the thread of execution and scheduling time be provided by 
> > > > > the caller, too?
>
>
> If the server can make guarantees about latency (which is useful anyway, to
> say the least), it should be able to tell how much schedule it needs.  Then it
> may demand that much from the client, and the client really transfers it, that
> is, it isn't gone when the client is destroyed.

Sth. similar came to my mind:
The caller calls the server. It grants a thread of execution (the thread 
musn't be revokable). It also grants a minimum schedule (needed to 
recover). The large part of the schedule can be passed revokably, if we 
have a fallback schedule mechanism. Maybye the same thing has to be done 
with memory (grant a bit, revokably grant the rest). This meant the 
server must be designed a way we can give upper bounds for memory and 
cpu time needed for leaving critical sections/cleanup. It _really_ 
complicates the server, but maybye a principle worth to discuss: don't 
set upper bounds for resources (this was the case in Hurd/Mach, AFAIK).

> The result is that the client can determine beforehand if the price is too
> high, and refuse to use the server if it thinks it is.
>
> What it needs is kernel support for such schedule donation.  Also, it needs
> support for "reserving" schedule, because a process can execute code (via an
> other process) after it is destroyed.  This will need a limit, and I'm not
> sure if that solves all problems.  In particular, kill -9 does no longer
> guarantee that the client will not perform a single instruction anymore.
>
> Are there any other problems with this approach?  Or is that one big
> enough...?
>
> Thanks,
> Bas
--
-ness-