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.
Received on Thu Jan 31 2013 - 17:09:14 MST
This archive was generated by hypermail 2.2.0 : Thu Jan 31 2013 - 12:00:08 MST