On 8/29/23 17:20, Daniel P. Berrangé wrote: > On Tue, Aug 29, 2023 at 05:13:08PM +0200, Michal Privoznik wrote: >> The point of calling sysconf(_SC_OPEN_MAX) is to allocate big >> enough bitmap so that subsequent call to >> virCommandMassCloseGetFDsDir() can just set the bit instead of >> expanding memory (this code runs in a forked off child and thus >> using async-signal-unsafe functions like malloc() is a bit >> tricky). >> >> But on some systems the limit for opened FDs is virtually >> non-existent (typically macOS Ventura started reporting EINVAL). >> >> But with both glibc and musl using malloc() after fork() is safe. >> And with sufficiently new glib too, as it's using malloc() with >> newer releases instead of their own allocator. >> >> Therefore, pick a sufficiently large value (glibc falls back to >> 256, [1], so 1024 should be good enough) to fall back to and make >> the error non-fatal. > > That's not suitable for macOS. THey have a constant OPEN_MAX we > should be using that is way bigger than 1024.
Yeah, it's 2^63-1 per: https://github.com/eradman/entr/issues/63#issuecomment-776758771 If we really use that it's going to take ages to iterate over all FDs. OTOH, the next commit switches over to /dev/fd where we can learn about opened FDs, so it's not that bad. Except we would be allocating humongous virBitmap (1 EiB). what seems to be the right default then? Michal
