Hanging in wl_event_loop_dispatch in WebKitGTK+WPE on FreeBSD

[valpackett]

Since WebKitGTK started using WPE, WebKitGTK apps were not working on Wayland on FreeBSD: the application would be frozen with no content rendered.
I've tried to debug today, and turns out just attaching the debugger and continuing unfreezes the application and everything works.

Where apps get frozen is in the wl_event_loop_dispatch that's called with no timeout (-1):

  * frame #0: 0x0000000806e957ca libc.so.7`_kevent + 10
    frame #1: 0x000000080316a783 libthr.so.3`___lldb_unnamed_symbol54$$libthr.so.3 + 83
    frame #2: 0x000000080862aafb libepoll-shim.so.0`epoll_wait + 315
    frame #3: 0x0000000806c3e9fd libwayland-server.so.0`wl_event_loop_dispatch + 77
    frame #4: 0x0000000807145128 libWPEBackend-fdo-1.0.so.1`___lldb_unnamed_symbol35$$libWPEBackend-fdo-1.0.so.1 + 4
    frame #5: 0x0000000803cec267 libglib-2.0.so.0`g_main_context_dispatch + 327

I see that this is only called when polling has returned that there is something to read, but somehow it's being called when it has nothing to read. Maybe GTK's Wayland dispatch call happened in between the source receiving the poll result and dispatch being called.

[valpackett]

I can't see any adverse effects from replacing that -1 with a 0 — everything started to work actually.. (Why would it be necessary to block here anyway? If we got the notification from the polling source, there must be something there — unless it was already dispatched by GTK — which is fine)

[zdobersek]

@myfreeweb can you list versions of the relevant libraries and programs? (wayland, libwpe, llibWPEBackend-fdo, WebKitGTK, relevant apps etc.)

[valpackett]

glib-2.60.4, gtk3-3.24.13, wayland-1.16.0, libwpe-1.4.0.1, wpebackend-fdo-1.4.0, webkit2-gtk3-2.26.3

---

This Wayland GSource code linked from this webkit issue uses 0 timeout. Same with libgwater, which provides an up-to-date wayland server source. And with this old clutter example. Clearly, the -1 here is a mistake.

[aperezdc]

Reading the documentation for wl_event_loop_dispatch I think that passing -1 is in theory the most correct thing to do, but using 0 should be harmless because it would return immediately if there are no events queued to read. Quote from the documentation:

A timeout of -1 disables the timeout, causing the function to block indefinitely. A timeout of zero causes the poll to always return immediately.

The odd thing is that the event loop is private to ws.cpp and dispatching events here should not affect anything else that GTK would be doing 🤔

@zdobersek: Any idea on how to proceed with this?

[zdobersek]

We can use 0.