Re: Comm API notes

On Wed, 2008-09-10 at 22:03 -0600, Alex Rousskov wrote:
> On Thu, 2008-09-11 at 14:34 +1200, Amos Jeffries wrote:
> > > On Thu, 2008-09-04 at 23:27 -0600, Alex Rousskov wrote:
> > >
> > > The comm_close API will be split into "stop I/O" and "kill me" APIs.
> > > New user code should not use comm_close for the purpose of ending a
> > > job (and should not assume it does). In most cases, the job has more
> > > tasks to do even if the descriptor is closed. AsyncJob API provides
> > > job-ending tools.
> >
> > Well, after reading the whole docs and your comment to Henrik earlier, I
> > don't see a point to the 'kill me' part of this.
> >
> > If a comm user wants to die based on the FD closing, then its close
> > handler should do it. Comm does not need to know when its users are
> > closing. Just like it does not need to know about non-comm calls. All it
> > needs to know is that it has a user handler to call or if Dialing that
> > handler failed.
> >
> > Some users will kill themselves when that handler is called, others will
> > shift their queueing to async calls for a slow wind down and cleanup. But
> > none of that can or need depend on comm.
>
> Exactly! The "kill me" functionality should not be a part of Comm API.
> In fact, it is already implemented as AsyncJob::mustStop() and via
> exceptions. Not all code has been converted to use that though and some
> code continues to use comm_close as "close fd and kill me".

Here is a replacement text:

  The comm_close API will be used exclusively for "stop future I/O,
  schedule a close callback call, and cancel all other callbacks"
  purposes. New user code should not use comm_close for the purpose of
  immediately ending a job via a close handler call.

Is this better?

Thank you,

Alex.
Received on Thu Sep 11 2008 - 04:15:40 MDT