On Wed Nov 30 16:59:15 2022 +0000, Zebediah Figura wrote:
What I'm trying to say is I don't see why cancelling pending callbacks is going to *help* anything. In general I can see two reasons, in a situation like this, to cancel or flush some queued event:
- in order to avoid letting that event execute after the cancel
- in order to prevent anything from taking extra time waiting for those
queued events to be processed Neither of these seem to apply here. The former can't apply because the race is still present, as has been described. The latter doesn't seem like it should apply either, since there's nothing actually waiting for those callbacks to execute.
I'm trying to eliminate those callbacks that are still in the submission phase (num_pending_callbacks). Those that have entered the execution phase (num_associated_callbacks) in tp_object_execute() cannot be stopped and will complete. Anyway, more than one pending callback per timer would be extremely rare, so no problem reverting that change.