On Fri, 2008-08-22 at 23:16 +0800, Adrian Chadd wrote: > Now, the reason I bring this up is in light of copy-free network IO. > Again, this requires the underlying buffer to persist until the write > is completed or is successfully cancelled. comm_write() uses cbdata > and will lazily ignore calling a callback if the pointer gets > invalidated, something I don't really like. Instead, I'm going to > experiment with a more "normal" approach found elsewhere - the > callback stays valid until the write is completed or invalidated; a > comm_close() or a call to a mythical comm_cancel_write() will result > in the write callback being called with write completion, either > cancelled or completed.
FWIW, I believe the above experimental design is similar to what we have (bugs notwithstanding) in Squid3: The term "callback" is a little overloaded so I will use "I/O registration object" to name a single I/O state from Comm point of view. That state includes an AsyncCall object that is used by Comm to notify the requester about the I/O completion. The state also includes a way to get to the data buffer and other I/O parameters. The I/O registration object must stay valid until all its users are gone. Otherwise, a user will not be able to cancel its interest in the I/O. When the I/O is completed (no matter how or by whom, including canceled I/O), the code calls the AsyncCall call stored in the I/O registration object. If that call has been canceled, the call is a no-op. There are simple rule(s) that define who can cancel the call, but I do not recall them exactly right now. The current code needs polishing, especially in the comm_close area because that function is currently used with different semantics depending on the context. IIRC, the usages are, at least: - "close and do not bother calling me" and - "close but let me know that you closed so that I can cleanup" That or similar inconsistency results in unexpected or missed calls. Documenting and fixing this is a part of the AsyncCall cleanup I am responsible for. As for the I/O buffer management, whether the buffer belongs to Comm or to the Comm user should be irrelevant to Comm I/O code and should not affect the overall Comm design, IMO. The buffers should be refcounted or otherwise protected from disappearing prematurely, but that is not a Comm problem. Both Squid2 and Squid3 still have that "free func" mess which should be replaced with proper refcounting. I believe Amos has already started a Feature page that documents the related issues for Squid3. $0.02, Alex.
