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 <[EMAIL PROTECTED]>: > 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. > > >
