On Wed, May 20, 2026 at 02:52:14AM +0200, Stefano Brivio wrote:
> On Mon, 18 May 2026 13:22:43 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > Most of our operation is asynchronous, based on non-blocking fds handled
> > in our epoll loop.  However, our several Unix sockets (tap client, repair
> > helper, control client) are all blocking fds after accept().
> > 
> > That is in fact correct, but for not especially obvious reasons that are
> > slightly different in each case.  Add explanatory comments to each of them.
> > 
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> >  conf.c   | 6 ++++++
> >  repair.c | 4 ++++
> >  tap.c    | 5 +++++
> >  3 files changed, 15 insertions(+)
> > 
> > diff --git a/conf.c b/conf.c
> > index 029b9c7c..5c7dfea1 100644
> > --- a/conf.c
> > +++ b/conf.c
> > @@ -2084,6 +2084,12 @@ static void conf_accept(struct ctx *c)
> >  	int fd, rc;
> >  
> >  retry:
> > +	/* Currently we perform the configuration transaction more-or-less
> > +	 * synchronously, so we want the accepted socket to be blocking.
> > +	 *
> > +	 * FIXME: We should make the configuration update asynchronous, like
> > +	 * most of our operation, so a misbehaving configuration client can't
> > +	 * block the main forwarding loop. */
> 
> Nit I fixed on merge:
> 
> 	* [...] loop.
> 	*/

Oh, thanks.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson