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

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.

> IMO in order to keep code flow same as before the async it needs to be
> written something like this:
>
> Using async calls the above become:
> 1) fd marked as closing, read and write handlers with COMM_ERR_CLOSING
> parameter scheduled for execution
>
> after some time ...
> - read/write handlers called with COMM_ERR_CLOSING
> 2) comm_close handlers scheduled for execution
>
> after some more time ...
> - comm_close handlers called
> 3) closing fd and initializing the fdc_table[fd] operations scheduled
> for execution
>
> And after even more time...
> - The fd closed and fdc_table[fd] initialized.
>
> Each step in the process scheduling the next as possible to keep them in
> sequence. With no single step scheduling the entire lot as seperate
> (possible async-reversable!) events.

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.

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.

Cheers,

Alex.

> > Henrik Nordström wrote:
> >> And why is this needed? The sendComplete callback should be invalidated
> >> if the HTTP connection state is no longer there.
> >>
> >> Adding this reshedule adds a noticeable overhead an delay, plus makes
> >> tracing of the code flow more difficult.
> >
> > The hope is that we are gaining in stability and less complex code
> > in upper levels.
> >
>
>
Received on Wed Jan 09 2008 - 00:04:35 MST