poll_dispatch_pending does not behave as expected

[ids1024]

poll_dispatch_pending is documented as "similar to" dispatch_pending. But the behavior doesn't seem quite as expected.

If I use wayland-client in a GTK application, spawning a thread calling dispatch_pending in a loop successfully dispatches events for the code using wayland_client (though it's a busy loop). blocking_dispatch() also seems to work, apparently without interfering with GTK's own use of Wayland.

But spawning an async task on glib's executor with poll_fn(event_queue.poll_dispatch_pending()) doesn't allow the wayland-rs code to receive events from Wayland. I guess something needs to call wl_display_dispatch_queue/wl_display_dispatch_queue_pending for the event queue for the dispatcher function to be called, which then wakes the async task? Not sure if there's a better way to implement this.

[ids1024]

The poll_dispatch_pending task does seem to work, however, if I have a task that calls prepare_read() and read(). But should it not work for reads like that done within GDK?

[elinorbgr]

Unfortunately, no. libwayland-client.so does not offer any way for us to know that GDK did read the socket and enqueue events for us to process. 😕

[ids1024]

That's unfortunate. I guess libwayland wouldn't want to run callbacks added by a different thread since they may not be thread-safe.

This behavior should be described somewhere in the documentation.

I think adding a GTK example would be good to show how to integrate wayland-rs with something else. I guess for simple uses at least, calling blocking_dispatch() in a loop in a separate thread from GTK's main UI thread is as good as any solution here? Or I guess the longer solution spawning async tasks to read and dispatch might make it possible to use one thread, which makes some things easier given GTK's types aren't thread-safe.

[ids1024]

#572 has such a GTK example. So if there's a better way to do it, it can be demonstrated in that example.