On Wed, Aug 30, 2023 at 08:26:02AM +0200, Michal Prívozník wrote:
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
IIUC, that's referring to the result of sysconf(_SC_OPEN_MAX) which is returning -1. I was refering to a literal constant OPEN_MAX which is reported as being 10k based on the debug logs shown in commit message of https://gitlab.com/libvirt/libvirt/-/merge_requests/283 With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|