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-
_______________________________________________
L4-hurd mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/l4-hurd
