Re: comm_write(), write cancellations, etc

On Mon, 2008-08-25 at 12:26 +0800, Adrian Chadd wrote:
> There's no way to guarantee sync termination of comm IO events in some
> environments, eg aio_read and aio_write on kernel-AIO platforms like
> FreeBSD.

Yes, the Squid3 design I am documenting guarantees call[back]
cancellation only. The underlying I/O may have already happened, is
happening, or may happen despite the call cancellation.

> You could hide that behaviour from the upper layers by making
> comm_close() not fully complete until IO completes (which it does for
> SSL, iirc); but any user resources passed into the comm call (such as
> a buffer) have to be reference counted before you pull that off as the
> kernel may still end up doing something with the buffer past the
> users' cancellation request.

Preserving buffers and other resources is the responsibility of the I/O
registration object that survives until nobody cares about that I/O.
Different I/O schemes may need to implement the I/O registration API
differently. I agree that I/O buffers should be eventually refcounted to
make the implementations simpler and cleaner.

> I agree that the comm_close() use as a "clean me up" trigger is not a
> good idea; comm_close() should just be a method of closing the
> filedescriptor and -comm- resources associated with it.
>
> There's still quite a bit of work though in making the existing code
> "do" what either/both of us are suggesting. Has there actually been a
> discussion and a plan for what this should look like long-term?

The distance between the current Squid3 code and the design I am
documenting is not huge anymore and we are working on shrinking it
further. And yes, we have discussed Squid modules, AsyncCalls, Comm, and
buffering quite a few times already. I think there was consensus on
these issues except for, perhaps, buffer handling which needs more
discussions (Amos has a corresponding Feature page on the wiki).

I have not seen Amos slides from the Australia meetup yet but I hope
they do not suggest any radical changes compared to what has been
discussed before that meeting.

Cheers,

Alex.

> 2008/8/25 Alex Rousskov <rousskov_at_measurement-factory.com>:
> > On Sat, 2008-08-23 at 08:31 +0800, Adrian Chadd wrote:
> >> 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.
> >
> > I doubt it is a good idea to try to force every job ordering the I/O to
> > wait for the I/O completion call. If the job has to terminate for some
> > reason, it should cancel its Comm call(s) and focus on the termination
> > business.
> >
> > Allowing the job to cancel its interest in I/O does not complicate the
> > Comm code (that does not care what the job does with the call). It does
> > simplify the job code (that does not have to "idle" while waiting for a
> > Comm call it no longer cares about).
> >
> > What often needs a cleanup is job code that uses comm_close() to
> > indirectly trigger that job cleanup and destruction. In most cases,
> > there are better ways to clean and terminate the job than relying on
> > Comm to eventually initiate that process even though the termination
> > reason had nothing to do with the pending Comm I/Os.
> >
> > HTH,
> >
> > Alex.
> >
> >
> >
Received on Mon Aug 25 2008 - 14:00:36 MDT