Clipboard on Wayland is interesting. Clients expose the content through wl_data_source and see wl_data_offer. To receive the clipboard content, they request receive on a wl_data_offer and pass a file descriptor (usually pipe() write end) to compositor, and then read from it. File descriptor is passed to the appropriate wl_data_source origin which is expected to write the content to it.

Both reads and writes ends take some time, I played with it to see how various programs react to a writer that just hangs or takes a lot of time. If the read is handled synchronously then you can block a UI loop. Some implement timeout and some can be blocked indefinitely.

But handling in asynchronously (either on thread or in nonblocking event loop) isn't an automatic win either. For example the new gnome text editor didn't order other user inputs with clipboard; so you would press Ctrl+V, nothing happened initially, continue writing and suddenly the clipboard content was inserted.

And I don't even remember how the OpenGL hidden window inhibiting worked with wl_data_source. Since the window is stuck in eglSwapBuffers, does it get unblocked to handle the clipboard write?

Surprisingly, even though Gnome compositor doesn't have a clipboard manager, it caches the clipboard content sometimes.