Re: comm_write(), write cancellations, etc

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.

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.

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?

Adrian

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 - 04:26:56 MDT