Re: comm_write(), write cancellations, etc

Well yes it is similar to what is done in Squid-3.HEAD except I'm
probably going to advocate a much more reduced functionality during
transition. I'm going to develop the replacement semantics and API on
the side, test it with a very reduced functionality codebase, make
sure I've handled all the cases and -then- look at migrating the
current Squid internals to use it. I'm also probably going to go for
"will always complete" versus the current cancellation models in
Squid-3. Ie, a cancelled IO transaction will still call the completion
callback with some kind of "error/cancelled" status; the callback
function can then cleanup as appropriate. That way you don't have to
try and handle unwinding a pending transaction in some other function
and call that wherever you -may- abort something.

Adrian

2008/8/23 Alex Rousskov <rousskov_at_measurement-factory.com>:
>
> 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.
>
>
>
Received on Sat Aug 23 2008 - 00:31:22 MDT