Re: client_side and comm_close

Maybe it can be easier:
Just keeping the comm_close as is and in AsyncCallsQueue just
cancels/not execute asyncCall's for which the fd_table[fd].flags.closing
is set.
We only need a way to identify comm_close handlers and the asyncCall
which will do the actual close of the socket.....

Alex Rousskov wrote:
> OK, I think you picked option B then :-). Let me polish it to better
> match the current level of understanding and the "dropping
> ERR_COMM_CLOSING" agreement:
>
> 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).
>
> 2) All close callbacks registered before comm_close was called will be
> called asynchronously, sometime after comm_close exits.
>
> 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.
>
> 4) Registering any callback after comm_close has been called is wrong.
> Comm will assert if it can detect such late registrations. Not all late
> registrations will be detected because the same FD can be already
> assigned to a different (new) connection[*].
>
> The above comm_close API is easy to implement without massive code
> changes. Do you think it is the right API? If not, what should be
> changed?
>
> [*] 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.
>
> Thank you,
>
> Alex.
>
>
>
Received on Tue Apr 22 2008 - 13:17:06 MDT