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

On Wed, 2008-01-09 at 21:13 +1300, Amos Jeffries wrote:
> Alex Rousskov wrote:
> > On Tue, 2008-01-08 at 16:19 +1300, Amos Jeffries wrote:
> >
> >> As you say this is headed toward SMP/threading and that may cause any of
> >> the scheduled steps to be run simultaneously or in a different order.
> >
> > We will cross that bridge when/if we have to. For now, the order of
> > async events firing is guaranteed to be the same as their scheduling
> > order. A lot of Squid code depends on that guarantee.
>
> You seem to have slightly missed my point.
> That this code is currently depending on that implicit guarantee when it
> should not be. This change is the perfect time to drop that implicit
> dependency and make it clean (bug free!).

The only relevant dependency/guarantee is that the file descriptor is
closed after all corresponding callbacks are called. That
dependency/guarantee cannot be removed (or, at least, it is not
AsyncCall job to do that).

The order of handler calls should not be important in the context of
this email thread (and yet AsyncCall work does not change the old
order).

> Having one precursor call
> schedule its successor is the cleanest and fastest way to do that.

In this particular case, there is no precursor or successor. Comm simply
notifies all interested parties that the FD is about to be closed. Also,
do not forget that comm does not know when a given async call is fired.
The caller is not notified when its call fires and the called handler
completes.

> > I do not know what async-reversable is, but I think what you propose is
> > practically equivalent to Christos code because async events never get
> > out of order.
>
> async-reversable is when things happening asynchronously CAN get out of
> order. And in wort case occur in reverse order of scheduling.
>
> Async generally means the thread/call/job is completely independant on
> any other currently scheduled. Any dependency make the dependent jobs
> synchronous regarding each other.

I would like to avoid talking in depth about true asynchronous execution
for now, but I believe you are mixing two distinct properties:
asynchronous execution of jobs and preservation of call order
originating from a single job. In many environments, asynchronous jobs
are guaranteed that their calls will not be reordered. Again, I do not
think we should spend much time on this currently-theoretical discussion
because a lot of old Squid code depends on call order preservation and
AsyncCall work will not change that dependency at this time.

> Squid is fast heading towards a state where the async queue might easily
> be split between processors. That means several fast finishing calls
> scheduled after a single slow-finishing might be run before the
> slow-finishing is done.

Let's talk about this when/if we actually decide to split async queue
between processors. We are not creating more work by not addressing
these questions now.

> > The only difference I can imagine is that in your scheme, a handler
> > called earlier (in step 2) can schedule another/new async call that will
> > be executed before handlers called in step 3. This should not make a
> > difference for correctly written handlers.
>
> The case which started this thread is a case in which the execution
> timing of (3) *does* effect other calls/handlers.

Not exactly. The problem was with the order of FD closing (which was not
an async call) and all async calls. We do not have that problem after
Christos moved FD closing into an async call handler (which is scheduled
last).

> Maybe I'm getting confused but your argument was that each async call is
> self-complete in state yes?

The call is, but the handler (job) may not be. Adrian was asking about
the call, not about the handler that the call triggers. Clearly, lots of
current handlers/jobs share state with other handlers/jobs.

> Keep state-automata in a mult-dimensional threaded environment etc. in
> mind during the current designs and they won't need re-designing next
> year when its implemented.

Currently, we are replacing a large set of custom sync calls with a
unified async call interface. The next step would be to address truly
asynchronous execution of jobs.

We are not creating a lot of extra work by not doing that second step
now; we are just postponing future work. This should allow us to reap
important AsyncCall benefits such as robustness and easy of debugging
without spending many more months on supporting truly async jobs.

> The calls for SMP support and threading in squid should not be as huge
> an overhaul as IPv6 was. It should be possible after async is merged to
> link some threading library and incrementally turn each async call into
> an independent thread.

A call is just a message exchanged between jobs. Jobs may become
independent threads, but calls will not.

Cheers,

Alex.
Received on Wed Jan 09 2008 - 08:07:22 MST