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
