Re: [libvirt PATCH 2/2] tests: don't set G_DEBUG=fatal-warnings on macOS

On Fri, Apr 29, 2022 at 01:05:42AM -0700, Andrea Bolognani wrote: > On Thu, Apr 28, 2022 at 05:55:41PM +0100, Daniel P. Berrangé wrote: > > On Thu, Apr 28, 2022 at 08:33:46AM -0700, Andrea Bolognani wrote: > > > 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 > > That's an excellent bug report! Thanks for spending time on it, and > let's see where the upstream discussion leads :) > Just so I don't sway the potential discussion in the issue to the wrong way, I'll ask here. Since BROKEN_POLL is used due to poll() on OS/X not behaving correctly with fds=NULL, nfds=0 [0], wouldn't it be possible to "fix" at least the internal calls to g_poll() which are done when running the main loop since they always have at least one FD (the eventfd used to signal the main loop [1])? I know it would not fix the problem, but it would at least workaround the part that is used the most, I presume.

[0] https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gpoll.c#L59