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

Alex Rousskov wrote:
> 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.

I still believe it should be done right the first time without delaying
the work. I guess we'll just have to disagree since you guys are the one
whose work it is.

>
>> 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.

Here we disagree again on the scale of lateralization, but thats
definitely a discussion for later years work when the SMP is done.

Anyway, don't let me stand in the way of this current development step
forward.

Amos

-- 
Please use Squid 2.6STABLE17 or 3.0STABLE1.
There are serious security advisories out on all earlier releases.