Re: client_side and comm_close

fre 2008-04-18 klockan 08:25 -0600 skrev Alex Rousskov:

> The changes needed on the client-side are pretty much unrelated to async
> calls. Async calls just make the design problems more obvious and help
> in solving them. Removing async calls from comm will fix a few bugs, but
> will be a step backwards and will make ongoing code cleanup more
> difficult.

Here is a different proposal. Split async calls in two. Queued and
immediate, with the event loops using immediate calls and everything
else queued. The siplest way of doing so safely would be to make async
calls immediate if not already within an async call, but adjusting the
event loops is also a possibility. This would make the code behave a lot
more like how it was before async, eleminating most races.

The very few cases which may depend on comm_close being immediate should
be possible to identify by cbdataInternalLock calls I think as the state
object previously may disappear immediately otherwise. I can't see any
in the client_side_* code today. But there very likely is assumptions
that after comm_close has been called no further events will fire
positively on that fd (only as ERR_COMM_CLOSING).

I don't remember why comm_close was made async, but the more I think
about it I think it's most likely wrong. comm_close SHOULD invalidate
any pending comm operations on that fd, anything else just leads to
nightmares.

Related to this I also think the COMM_ERR_CLOSING callback from comm
should be dropped. Nearly all handlers looking for COMM_ERR_CLOSING do
nothing else than return immediately to abort execution.. and the few
exceptions there is can be dealt with by a close callback if at all
needed:

errorSendComplete, invalidates the err object

ftpStateData::dataRead, sets a boolean that the read is done

HttpStateData::handleRequestBodyProducerAborted injects a
COMM_ERR_CLOSING

HttpStateData::readReply sets a boolean that the read is done

ServerStateData::sentRequestBody clears requestSender

the other 20 or so users of comm callbacks just returns immediately on
COMM_ERR_CLOSING, "aborting" the call..

Regards
Henrik
Received on Tue Apr 22 2008 - 13:03:43 MDT