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