Re: client_side and comm_close

Alex Rousskov wrote:
> On Sun, 2008-04-20 at 22:01 +0300, Tsantilas Christos wrote:
>> Maybe it can be easier:
>
> The ease of implementation is a separate question. We still have to
> agree what we are implementing, and the items below attempt to define
> that. Ambiguity and lack of clear APIs is quite dangerous here (as the
> related bugs illustrate!).

In practice I am proposing to keep the current design but just do not
allow any AsyncCall executed after the comm_close called (now we are
allowing it).

In your design just do not close the socket with the comm_close but
schedules a call to close it, this will not allow the fd used by a new
connection.

>
>> We only need a way to identify comm_close handlers and the asyncCall
>> which will do the actual close of the socket.....
>
> I am not sure what you mean, but the general-purpose AsyncCallQueue will
> not do these comm-specific checks. We already have custom comm callbacks
> and a general "Should This Call be Dialed?" interface. The callbacks
> will check the flags and will not dial if they should not. Please
> clarify if I am talking about a different problem here.

No you are talking for the same problem but you are giving a better
solution :-)

>
> Thank you,
>
> Alex.
>
>> Alex Rousskov wrote:
>>> 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.
>
>
>
Received on Tue Apr 22 2008 - 14:14:44 MDT