bug#24869: 26.0.50; Emacs should not force lower FD limit on subprocesses

[Brendan O'Dea]

On Thu, Nov 03, 2016 at 07:10:40PM +0100, Philipp Stephani wrote:
>$ ulimit -n
>32768
>$ emacs -Q -f shell
>
>In the Emacs Shell buffer, run 'ulimit -n' again, the limit will be
>1024.
>Internally this limit is required because Emacs uses fd_sets, but it
>shouldn't be inherited to subprocesses.  Probably Emacs should reset
>RLIMIT_NOFILE in subprocesses to the original value.

This behaviour was introduced by the fix to Bug#24325:

  
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a5509099484e0762842bc2c9e914779397b91469

Given that child processes will inherit that limit, this causes unnecessary
problems for forked processes (think: M-x compile RET make -j).

A potential fix would be to stash the initial limit before changing it, and
then restore that limit in child_setup().

My inclination however would just be to revert that entire change: AFAICT it
merely moves the problem from emacs crashing under some aberrant behaviour, to
emacs no longer working under that same behaviour due to system calls randomly
failing with EMFILE.

--bod