From: Phillip Wood <phillip.wood123@gmail.com>
To: "Carlo Marcelo Arenas Belón" <carenas@gmail.com>, git@vger.kernel.org
Cc: yoshfuji@linux-ipv6.org, kristofferhaugsbakk@fastmail.com
Subject: Re: [PATCH v2] daemon: correctly handle soft accept() errors in service_loop
Date: Fri, 27 Jun 2025 09:38:47 +0100 [thread overview]
Message-ID: <08804dbe-56dd-4c0e-b36b-a82768b0aa29@gmail.com> (raw)
In-Reply-To: <20250626172159.87204-1-carenas@gmail.com>
Hi Carlo
On 26/06/2025 18:21, Carlo Marcelo Arenas Belón wrote:
> Since df076bdbcc ([PATCH] GIT: Listen on IPv6 as well, if available.,
> 2005-07-23), the original error checking was included in an inner loop
> unchanged, where its effect was different.
>
> Instead of retrying, after a EINTR during accept() in the listening
> socket, it will advance to the next one and try with that instead,
> leaving the client waiting for another round.
>
> Make sure that the loop doesn't advance
That makes sense
> and while at it, make sure
> that any possible completed children get reaped earlier.
What's the rationale for that? It means we end up calling
reap_dead_children() twice which sounds inefficient. If it is important
then I'm also struggling to see how it fits in with the proposal to use
SA_RESTART
> To avoid an
> unlikely busy loop, fallback to the old behaviour after a couple
> of attempts.
>
> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
> ---
> daemon.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/daemon.c b/daemon.c
> index d1be61fd57..f113839781 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -1145,6 +1145,7 @@ static int service_loop(struct socketlist *socklist)
>
> for (size_t i = 0; i < socklist->nr; i++) {
> if (pfd[i].revents & POLLIN) {
> + int incoming;
> union {
> struct sockaddr sa;
> struct sockaddr_in sai;
> @@ -1153,11 +1154,19 @@ static int service_loop(struct socketlist *socklist)
> #endif
> } ss;
> socklen_t sslen = sizeof(ss);
> - int incoming = accept(pfd[i].fd, &ss.sa, &sslen);
Why is the declaration of incoming moved but retry is declared here?
Thanks
Phillip
> + int retry = 3;
> +
> + redo:
> + incoming = accept(pfd[i].fd, &ss.sa, &sslen);
> if (incoming < 0) {
> switch (errno) {
> - case EAGAIN:
> case EINTR:
> + if (--retry) {
> + check_dead_children();
> + goto redo;
> + }
> + /* fallthrough */
> + case EAGAIN:
> case ECONNABORTED:
> continue;
> default:
next prev parent reply other threads:[~2025-06-27 8:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 16:10 [PATCH] daemon: correctly handle soft accept() errors Carlo Marcelo Arenas Belón
2025-06-26 16:15 ` Kristoffer Haugsbakk
2025-06-26 17:21 ` [PATCH v2] daemon: correctly handle soft accept() errors in service_loop Carlo Marcelo Arenas Belón
2025-06-27 8:38 ` Phillip Wood [this message]
2025-06-27 19:05 ` Carlo Marcelo Arenas Belón
2025-06-27 20:19 ` Junio C Hamano
2025-06-27 23:05 ` Carlo Marcelo Arenas Belón
2025-06-27 23:25 ` Hridoy Ahmed
2025-06-27 23:53 ` Junio C Hamano
2025-06-30 8:59 ` Phillip Wood
2025-06-27 23:14 ` [PATCH v3] " Carlo Marcelo Arenas Belón
2025-06-30 9:00 ` Phillip Wood
2025-06-30 15:33 ` Junio C Hamano
2025-07-01 19:33 ` Phillip Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=08804dbe-56dd-4c0e-b36b-a82768b0aa29@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.