in squid 2 & 3 we use the following general approach for callbacks: // lock callback data // call callback based routine someObject.someRoutine(parameters, cbdata, callbackroutine) return
someRoutine then does: // save callbackdata self->callback=callbackroutine self->cbdata=cbdata // kick off async activity and eventually: // call callback callback=self->callback cbdata=self->cbdata callback(cbdata, someresult,...) return I've been playing with Twisted (www.twistedmatrix.com) for a while, as part of a work project. other than language it greatly resembles squid. (single threaded, async, callback..) One interesting pattern they have is the 'deferred' pattern. http://www.twistedmatrix.com/documents/current/api/twisted.internet.defer.html http://www.twistedmatrix.com/documents/howto/defer I'd like to suggest that we adopt this for squid 3.1 development. What would it do for us? *) the Deferred approach decouples success & failure handling for callbacks, leading to cleaner code. *) the api for calling callback routines decouples the generation of results, and the calling of the recievers - rather than passing in where to call, and with what, a callback routine just returns a deferred instance that represents what it will generate later. This allows runtime decisions to (for instance) process io data on the next event loop, or immediately on the callstack. *) common idioms for callbacks can be centralised and reused. roughly, using a deferred is done as follows deferred=someObject.someRoutine(parameters) deferred.addCallback(method, self) // locking done for us deferred.addErrback(method, self) // ditto return someRoutine then does: // allocate a deferred self.deferred=Deferred<type signature>() // kick off async activity return self.deferred and eventually: // call callback self.deferred.callback(result) //or self.deferred.errback(Failure) return Unless we use RTTI and a common base type, we'll need to use a template Deferred as I show above, sacrificing some of the flexability of the Deferred that twisted has - but I don't think that that will be a significant issue. Regardless, I'd write up a Deferred example set of tests and uses to see how it fits with what we do, before incorporating it into squid. The real question is - what do y'all think? Rob
signature.asc
Description: This is a digitally signed message part
