On Thu, Apr 28, 2022 at 08:33:46AM -0700, Andrea Bolognani wrote: > On Thu, Apr 28, 2022 at 02:52:45PM +0100, Daniel P. Berrangé wrote: > > > #else > > > if (select() < 0) > > > if (!EBADF) > > > return -1; > > > #endif > > > > > > > > instead? If acting on an fd that's already been closed is okay when > > > using the poll()-based implementation, the same should apply to the > > > select()-based one as well. > > > > The only way to get the same semantics for select() would be to see > > EBADF and then iterate over struct pollfd, calling fcntl() to see > > which one(s) are BADF. Possible, but its unpleasantly non-scalable, > > so I imagine that's why they didn't do this. > > IIUC g_poll(), just like any other function used as GPollFunc, is > supposed to have the same semantics as poll()[1], which means that > passing an invalid FD should result in the corresponding flag being > set rather than an outright failure. > > In other words, the current implementation of g_poll() on macOS > doesn't follow the contract defined by GLib itself. It seems to me > that this is a (fairly serious) bug in the library, no? It is significant, but long standing. GLib actually had this behaviour forever on macOS, but it regressed when Meson was introduced, until the recent fix. The question is whether efficiency trumps API semantics. Normally I'm heavily biased towards API semantics, but poll is a performance critical API, so it isn't so easy to declare we must workaround all the quirks. I filed a bug to raise the subject for discussion though https://gitlab.gnome.org/GNOME/glib/-/issues/2644 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 :|
