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