[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 22:19:33 +0100
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051031)

Jonathan S. Shapiro wrote:
On Thu, 2005-11-10 at 21:01 +0100, ness wrote:

Jonathan S. Shapiro wrote:

On Thu, 2005-11-10 at 20:00 +0100, ness wrote:

The client cannot grant a guarantee that the client does not have. The
client's schedule is revocable, therefore any schedule that it might
grant is revocable.

Why should a given schedule be revokable?

If you cannot revoke schedule, how do you correct an erroneously issued

I'm not an expert and I have not yet read anything about reservation based scheduling, but let me raise the question: why should a schedule be issued erroneously?

Because I type "1ms in 50ms" when I meant "2ms in 100ms", or because I
start a program with a schedule and later realize that I do not want it
to run.

Hm. So the implications are as follows:
There are operations in exectution that must be finished, and they must be finished in a reasonable time. They might operate on memory, so this memory has to be available for a reasonable time (the time the operation needs). We want the caller to pay for what he wants. So at least parts of the memory and cpu time given by him have to be unrevokable. So the caller needs the ability to provide unrevokable memory and cpu time (well, at least both caller and callee have to trust the source of the memory/cpu time not to revoke it; of course unrevokablility might be testable). This means, things like kill -9 cannot work.
How can this be solved (regardless to cost-value ratio)?
Maybye additionally to standard schedules very less non-revokable schedules could be issued. This wouldn't make kill -9 work, but if it are few enough non-revokable it would act mostly like one expected it in a system where the caller doesn't pay. Of course it would be hard to find the amount of non-revokable schedules to be issued, or only a reasonable default. But my proposal would add even more complexity, and I dunno whether one should call it rsonable, as tools like kill -9 would work like before...

reply via email to

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