Tsantilas Christos wrote:
The problem was different:
With classic comm code of squid3 when the comm_close for a fd called then:
1) fd marked as closing, read and write handlers called with
COMM_ERR_CLOSING
2) comm_close handlers called
3) the fd closed and the fdc_table[fd] initialized.
Using async calls (current code) the above become:
1) fd marked as closing, read and write handlers with COMM_ERR_CLOSING
parameter scheduled for execution
2) comm_close handlers scheduled for execution
3) closing fd and initializing the fdc_table[fd] operations scheduled
for execution
And after some time:
- read/write handlers called with COMM_ERR_CLOSING
- comm_close handlers called
- The fd closed and fdc_table[fd] initialized.
If the fd closed before the comm_close handlers executed bad thinks
happens.....
I'd agree with that. However in moving from a single-thread to an async
situation there are undesirable consequences with time that were
inherent in the previous model but need to be explicitly designed into
async.
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.
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.
If the fdc operations for close are simple enough they could be rolled
into the call doing close_handlers step 3 to speed them up.
Amos
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.
--
Please use Squid 2.6STABLE17 or 3.0STABLE1.
There are serious security advisories out on all earlier releases.
