On Tue, 2008-01-08 at 13:21 +0900, Adrian Chadd wrote: > On Mon, Jan 07, 2008, Alex Rousskov wrote: > > > > Finally, I can't see how async callbacks will make SMP much easier to > > > implement. > > > Could someone give me some insight into this? > > > > The AsyncCall API can be used to call threads or processes without > > changing the caller or the callee code. Selected AsyncJob kids could > > become threads or even processes after their dependence on global > > variables is reduced. > > How do you guarantee that something else hasn't modified the "state" > being passed into the async call?
This may be a too general question to answer precisely, but calls simply pass constant (from their point of view) data from the caller to the callee. There is no modification going on during that process. > Thats the exact problem seen in the commit which started all of this > discussion. IMO, the problem was that comm was closing a FD before close handlers were called. It was as wrong as freeing object memory before calling the class destructor. The async calls involved in that problem did not (and do not) care about the FD state or its change; they just pass constant info from comm to the callback handler. The global or job state can change while some calls are pending, of course. The job code must be written to handle such change. Old Squid code has lots of examples of doing so. AsyncCalls may streamline some handlers (e.g., they remove reentrant calls), but they cannot somehow remove the fundamental problem of coordinating asynchronous jobs. Alex.
