Re: client_side and comm_close

On Sun, 2008-04-20 at 22:58 +0300, Tsantilas Christos wrote:
> 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).

One of the problems is that the "current design" is partially undefined
and, hence, is being interpreted or broken differently by different
code. That's why I want to polish and document the API while we are
fixing related problems.

I know you prefer to talk about specific "code" but "keeping the current
design" does not mean much to me in this context, unfortunately (for the
reasons mentioned above).

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

Actually, I do not think the proposed rules mentioned closing the
socket! Who cares about such a minor internal detail :-?

The FD must be closed sometime after the last close callback returns, I
guess. I will add that to the comm_close rules we are hashing out in
this thread (I want to refresh my memory on overlapping I/Os per Adrian
suggestion first).

Thank you,

Alex.
Received on Tue Apr 22 2008 - 12:37:05 MDT