All of Alex' objections to the cancelling are - of course - completely well-founded and this should really work in the way he described it. The problem is just "that's not how the existing code works". I spent some time thinking how a 'nicer' cancellation subsystem with all desirable properties (both 'simple to use' and 'efficient to implement' could look like). Below is a sketch of that, feedback very much appreciated (May overlap with existing facilities. ATM, this is supposed to be abstract).
- create abstract base class 'call queue' with virtual methods 'schedule' and 'cancel' - create another abstract base class 'call' with virtual methods 'take' and 'cancel' Something desiring to schedule a call would then create a call object and pass that as argument to the schedule method of a 'call queue' object. This object would do whatever is necessary to put this call onto its queue and invoke the 'take' method in order to take ownership of this call, passing a pointer to itself and 'some data item' as arguments. Assuming the original creator of the call wants the cancel it, it would invoke the cancel method of the call which would - in turn - invoke the cancel method of its current owner, passing a pointer to itself and the data item handed over when the 'call queue' took ownership. The 'call queue object' cancel method would then use this information in order to 'get rid of the call', whatever may be necessary to do that. NB: I haven't done any 'OO programming' in something other than perl since about 2001, when I stopped using C++ because of a mixture of 'real-world requirements' (peaceful coexistence with 'C programmers') and frustration about the state of g++ at that time.
