On Wed Feb 5 10:45:49 2025 +0000, Rémi Bernon wrote:
Why do we need to do all this already (ie: timeouts and non-blocking I/O)? I think it would be much better if it could be avoided entirely.
The Wayland wl_data_device interface involves direct client-to-client data transfers. The file descriptor we write the clipboard data to (sent to us in the `wl_data_source.send` event) is typically the write end of a pipe, whose read end is under the direct control of the Wayland client requesting the data. If that other client is misbehaving, it can potentially cause our write to block indefinitely, e.g., if we need to transfer enough data to fill up the pipe kernel buffer while the other client is not consuming anything. The timeout is a simple mitigation for this scenario.
Another approach used by many Wayland clients is to use some kind of asynchronous write/read which will notify when finished (typically the fds are `poll`ed and read/written in the context of the main event loop). However, this is a lot of extra complexity for likely diminishing returns (IMO) for our case. See also note (3) in the MR description.