The example scheduler callback unconditionally frees resources for any request in the CANCELLING state.
def callback(self, rset):
""" Scheduler request callback. """
rospy.logdebug('scheduler callback:')
for rq in rset.values():
rospy.logdebug(' ' + str(rq))
if rq.msg.status == Request.NEW:
self.queue(rset.requester_id, rq)
elif rq.msg.status == Request.CANCELING:
self.free(rset.requester_id, rq)
Even for the simplified assumptions of "one resource per request" and "all resources satisfy any request", that is only correct for requests that were previously in the GRANTED or PREEMPTED states. If a request in the NEW, RESERVED or WAITING state is canceled, the available resource pool becomes corrupted.
Of course, a real scheduler must keep track of what requests own each resource. But, I would prefer that the example not exhibit this bug. Furthermore, a simple scheme for figuring this out would be helpful.
The example scheduler callback unconditionally frees resources for any request in the CANCELLING state.
Even for the simplified assumptions of "one resource per request" and "all resources satisfy any request", that is only correct for requests that were previously in the GRANTED or PREEMPTED states. If a request in the NEW, RESERVED or WAITING state is canceled, the available resource pool becomes corrupted.
Of course, a real scheduler must keep track of what requests own each resource. But, I would prefer that the example not exhibit this bug. Furthermore, a simple scheme for figuring this out would be helpful.