I agree with the general principle that if we open it, we track it, and
then close it so it doesn't reach the child, typically with O_CLOEXEC or
FD_CLOEXEC. Calling close(2) lots of times based on getdtablesize(3)
can take a while. screen(1) had a bug recently where it was taking ages
trying to close almost 512 Ki of them.
https://lists.archlinux.org/pipermail/arch-general/2019-March/046214.html
I was curious what they did, so I looked ... it looks like they actually
didn't really "solve" the issue. They use a function fdwalk() on Solaris
but made sure they called getdtablesize() on Linux, which it seems returns a
smaller number than getrlimit().
--Ken
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers