Re: client_side and comm_close

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.

> 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, and what
should be done for 3.1 I think.

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

> 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..

Regards
Henrik
Received on Tue Apr 22 2008 - 13:00:20 MDT