Re: async-calls squid3/src comm.cc,1.81.4.16,1.81.4.17

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.
Received on Mon Jan 07 2008 - 23:02:24 MST