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

[Stefan Metzmacher]

Am 30.09.22 um 14:00 schrieb Stefan Metzmacher via samba-technical:
> Am 30.09.22 um 13:31 schrieb ronnie sahlberg via samba-technical:
>> 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.
> 
> The question is why does epoll report EPOLLOUT in that case.
> If we don't get that and get EPOLLERR|EPOLLHUP we should
> disable reporting unless TEVENT_FD_READ is requested.
> 
> See epoll_event_loop() and epoll_handle_hup_or_err().

Is this plain tcp or via tls?

metze