GNU bug report logs - #66288
29.1; Performance regression using pipe for subprocess

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: gerd.moellmann <at> gmail.com, dmitry <at> gutov.dev, gregory <at> heytings.org, cph <at> chris-hanson.org, 66288 <at> debbugs.gnu.org
Subject: bug#66288: 29.1; Performance regression using pipe for subprocess
Date: Thu, 05 Oct 2023 08:49:02 +0300

> Date: Wed, 4 Oct 2023 15:49:00 -0700
> Cc: dmitry <at> gutov.dev, gregory <at> heytings.org, gerd.moellmann <at> gmail.com,
>  66288 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 10/3/23 23:52, Eli Zaretskii wrote:
> 
> 
> > +#if defined(GNU_LINUX) && defined(F_SETPIPE_SZ) && defined(F_GETPIPE_SZ)
> 
> A small point: no need to check whether GNU_LINUX is defined; any system 
> having these two Linux macros should be Linux-compatible.
> 
> > +      /* If they requested larger reads than the default system pipe
> > +         capacity, enlarge the capacity to match the request.  */
> > +      if (read_process_output_max > fcntl (inchannel, F_GETPIPE_SZ))
> > +	{
> > +	  int readmax = clip_to_bounds (1, read_process_output_max. INT_MAX);
> 
> "." -> "," of course.
> 
> > +	  fcntl (inchannel, F_SETPIPE_SZ, readmax);
> 
> This call can fail if you aren't root and you exceed the system limit in 
> /proc/sys/fs/pipe-max-size. So I suggest that if this fnctl fails with 
> EPERM, trying it again after clipping to that limit.

Thanks.

I thought to ignore EPERM in this case, at least for the release
branch, since we already have that problem there.  And even for
master, what are the downsides of ignoring EPERM here? accessing
/proc/sys/fs/pipe-max-size is a bit of a hassle (and AFAIU does make
this less portable, since we need support for /proc).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.