The current scheduler module allows a requester to hang on to a preempted resource indefinitely. That may be useful in some cases, but relies on all requesters to be responsive and well-behaved. While the scheduler protocol is intentionally co-operative, providing a timeout does seem desirable for cases where the requester is not working correctly.
We want a mechanism for the scheduler to allow a reasonable period of time for clean-up without tying up resources forever. Since a fixed time is unlikely to work for all situations, the requester and scheduler should negotiate how long to wait using the hold_time and availability fields. The scheduler's preempt() call would set availability to some reasonable time limit, and the requester could update hold_time if it has different requirements.
See #10 for a lengthy discussion of some aspects involving lost resources.
The current scheduler module allows a requester to hang on to a preempted resource indefinitely. That may be useful in some cases, but relies on all requesters to be responsive and well-behaved. While the scheduler protocol is intentionally co-operative, providing a timeout does seem desirable for cases where the requester is not working correctly.
We want a mechanism for the scheduler to allow a reasonable period of time for clean-up without tying up resources forever. Since a fixed time is unlikely to work for all situations, the requester and scheduler should negotiate how long to wait using the
hold_time
andavailability
fields. The scheduler's preempt() call would setavailability
to some reasonable time limit, and the requester could updatehold_time
if it has different requirements.See #10 for a lengthy discussion of some aspects involving lost resources.