[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: ness
Subject: Re: On PATH_MAX
Date: Thu, 10 Nov 2005 16:02:28 +0100
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051031)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]