bug#66288: 29.1; Performance regression using pipe for subprocess

[Eli Zaretskii]

> Date: Wed, 4 Oct 2023 15:49:00 -0700
> Cc: dmitry@gutov.dev, gregory@heytings.org, gerd.moellmann@gmail.com,
>  66288@debbugs.gnu.org
> From: Paul Eggert <eggert@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).