Re: client_side and comm_close

On Mon, 2008-04-21 at 00:54 +0200, Henrik Nordstrom wrote:
> sön 2008-04-20 klockan 11:21 -0600 skrev Alex Rousskov:
> > I agree regarding the first initiation point, but disagree that it is
> > sufficient to guarantee non-recursive behavior: In addition to
> > callbacks, we have direct function calls to comm and other APIs. The
> > combination of immediate callbacks and those function calls will cause
> > "recursion" as control will reenter the jobs multiple times. For
> > example:
> >
> > event loop -> immediate callback -> handler -> comm_* call -> immediate
> > callback -> handler -> ...
>
> No, there is already an AsyncCall in progress so the call from comm_*
> will always be async.

Ah, I think I see what you mean now. I would very much like to avoid or
at least minimize this mixture of asynchronous and immediate calls,
especially if one call is going to determine the other call "timing".
Let's see what we really need once comm_close API is finalized.

> > comm_close(fd) API:
> >
> > 1) No I/O callbacks will be dialed after comm_close is called (including
> > the time when comm_close is running).
>
> Yes.
>
> > 2) All close callbacks registered before comm_close was called will be
> > called asynchronously, sometime after comm_close exits.
>
> Yes.. or... no. See below.
>
> > 3) The code can ask Comm whether a FD associated with a close callback
> > has been closed. The answer will be "yes" after comm_close is called and
> > "no" before that. This interface needs to be added. Direct access to
> > fd_table[fd].flags will not work because the same FD could have been
> > assigned to another connection already. The code will have to use its
> > close callback to determine FD status.
>
> Right. There is a trouble here in that we only have the fd, not a "Comm
> handle". So we need to defer the actual closing of the fd until all
> close handler have executed, but make comm behave as if it was closed.
>
> Or the comm_close callbacks should most likely be synchronous to let
> each user of the fd know the fd is now going away and that they MUST NOT
> take any other actions on that fd.
>
> The second is more in line with what the current code expects,

Yes, we are on the same page here and #4 below.

> and what should be done for 3.1 I think.

What if we let the close callback to determine how it should be called?
Old code gets an "immediate" close callback (the default in v3.1). The
code that was written to handle async calls uses asynchronous callbacks.
This approach may allow for a smoother migration to 100% asynchronous
calls without introducing new complex inter-call dependencies. I believe
this approach is also easy to implement without changing much of the
existing code (old or new).

> For 3.2 we may rethink the comm layer, eleminating this.

Thank you,

Alex.

> > 4) Registering any callback after comm_close has been called is wrong.
>
> yes. The fd is semantically gone at that point.
>
> > [*] We can reliably detect #4 violations by replacing "fd" integers
> > outside of comm with a unique integer ID or, better, a handler object
> > containing metadata. That kind of change may be too big for v3.1 though.
>
> Yes. Long term we should have a "Comm handle" separate from the fd, with
> the lowlevel OS fd only known to comm.
>
> And additionally it should be possible to layer things on that which
> further abstracts I/O from the fd, such as ssl.. but that's another
> topic..
Received on Tue Apr 22 2008 - 12:51:51 MDT