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 :|
