How to detect a client-closed connection during a write from our LDAP server?

[Isaac Boukris]

On Fri, 2022-09-30 at 21:31 +1000, ronnie sahlberg via samba-technical
wrote:
> On Fri, 30 Sept 2022 at 21:12, Isaac Boukris via samba-technical
> <samba-technical at lists.samba.org> wrote:
> > 
> > On Fri, 2022-09-30 at 14:26 +1300, Andrew Bartlett via samba-
> > technical
> > wrote:
> > > I've been trying to chase down the CPU spins reported by our
> > > users in
> > > the writev() codepath from our LDAP server.
> > > 
> > > A private mail the the strace output shows the sockets are in
> > > CLOSE_WAIT state, returning EAGAIN over and over (after a call to
> > > epoll() each time).  That alone would be enough to keep things
> > > spinning.
> > > 
> > > But they are being shut down, however our LDAP server won't be
> > > triggering a read any time soon, it is waiting to flush the
> > > response
> > > out.
> > 
> > Why wouldn't it? I mean why does the read waits for the write? if
> > epoll
> > says so then we should read, then we may detect that the client
> > closed
> > it end and may decide to give up the writes.
> > 
> > Technically, I think there is no problem to write to a socket after
> > the
> > peer sent us FIN,
> 
> I think possibly the problem is that IF the tcp tx buffer is full,
> you
> might get -EAGAIN instead of a better error
> if the socket is only half-closed.

Yeah the EAGAIN is probably due to tx buffer full, since in this case
the client probably stopped reading, but otherwise you should be able
to write and the client should be able to read, since the socket is
only half-closed. I wonder what are the events reported by epoll..

> > it just mean he closed its end and won't write no
> > more, but we can still write until we close or he/we reset (as is
> > the
> > case with HTTP 1.0).
> > 
>