On Wed Feb 5 12:47:07 2025 +0000, Alexandros Frantzis wrote:
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.
Are every Wayland client out there really expected to guard against any possible other badly implemented client out there? This sounds like a truly awful design to me.
IMO bogus applications need to be fixed, not force upon every other the burden of guarding against their bugs.