--- a/src/utils/closefrom.cpp
+++ b/src/utils/closefrom.cpp
@@ -25,8 +25,8 @@
* libraries.
*
* There are many reasons for closing file descriptors before
- * an exec (security, pipe control, the possibility that a bug will trigger
- * an unwanted write, etc.)
+ * an exec (security, pipe control, the possibility that a bug will
+ * trigger an unwanted write, etc.)
*
* A process has currently no POSIX way to determine the set of open file
* descriptors or at least the highest value. Closing all files (except a few),
@@ -54,9 +54,10 @@
* - Solaris 10+ has closefrom, and can specify closefrom to posix_spawn()
*
* Linux:
- * - Has nothing. The method we used (opening /dev/fd) was very
- * unsafe in multithread fork/exec context. We now use a close()
- * loop. glibc maintainers think that closefrom() is a bad idea
+ * - Has nothing. The method we initially used (listing /dev/fd) could
+ * deadlock in multithread fork/exec context. We now use a close()
+ * loop but there is no completely reliable way to determine the high limit.
+ * glibc maintainers think that closefrom() is a bad idea
* *especially* because it is implemented on *BSD and Solaris. Go
* figure...: https://sourceware.org/bugzilla/show_bug.cgi?id=10353
*
@@ -206,6 +207,12 @@
}
#endif
+// Note that this will not work if the limit was lowered after a
+// higher fd was opened. But we don't call setrlimit() inside recoll
+// code, so we should be ok. It seems that sysconf(_SC_OPEN_MAX)
+// usually reports the soft limit, so it's redundant, but it could be
+// useful in case getrlimit() is not implemented (unlikely as they're
+// both POSIX.1-2001?
int libclf_maxfd(int)
{
struct rlimit lim;