Moved from utexas-bwi/rocon_scheduler_requests#28:
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 utexas-bwi/rocon_scheduler_requests#10 for a longer discussion of some aspects involving lost resources.
Moved from utexas-bwi/rocon_scheduler_requests#28:
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_timeandavailabilityfields. The scheduler's preempt() call would setavailabilityto some reasonable time limit, and the requester could update hold_time if it has different requirements.See utexas-bwi/rocon_scheduler_requests#10 for a longer discussion of some aspects involving lost resources.