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

[Martin Kletzander]

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.

Martin

[0] https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gpoll.c#L59
[1] this is a presumption I did not find in the code, but I've seen in
     gdb and strace
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20220502/ab5fb1e1/attachment.sig>