Re: comm_write(), write cancellations, etc

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 Fri Aug 22 2008 - 23:41:57 MDT