How to rely on file sealing in protocol extensions?
In swick/wayland-protocols!54 (closed) we have been trying to figure out how we could make use of file sealing in order to make the receiver's life easier. This seems to be very difficult even for a completely new protocol extension.
Linux style file sealing could be used to make memory-mapping files safe against truncation, meaning that SIGBUS cannot happen. Sealing could also guarantee that the file contents cannot change anymore, at least for memfd which happens to be the only file type that currently supports sealing on Linux. Since it is memfd, it cannot be on a slow disk or a slow network file system (swapping notwithstanding). These are all very useful properties that make the fd receiver's implementation easier, if the seals can be guaranteed by the protocol.
What's the problem with simply writing in protocol spec that the fd must be sealed?
- Not all OSs implement file sealing. There are only Linux and one flavor of BSD?
Why not spec that the fd must be sealed on Linux?
- That would work for Linux, but leave all other OSs out. A portable compositor or client implementation would need the code for both sealed and not sealed fds.
How about spec'ing that the fd must be sealed on any OS that supports sealing?
- That will create a problem on an OS that at first does not implement sealing, the protocol extension becomes used there, and then the OS implements sealing. All compositors and clients suddenly violate the spec wording. If some protocol implementations then start to require sealing, that will regress other implementations that do not seal fds when sending them.
One can imagine several variations of the above, but in the end result seems to be either everyone has to support also non-sealed fds, or implementations on some OSs need to support (also) non-sealed fds. It seems the proper support for non-sealed fds in a safe way requires a) a new thread to operate in, and b) avoid mmap(). (wl_shm implementations may handle SIGBUS, but I would guess that none of them can tolerate files on very slow file systems, causing unexpected stalls. OTOH, maybe wl_shm texture uploads should be in a new thread anyway?)
If non-sealed fds must be supported anyway, why bother at all with sealing to begin with?
- It might be a performance improvement in some use cases. If a fallback aims to tolerate slow file systems, it probably needs to make a copy of the data one way or another. If the data is relatively small, I don't see any reason to bother with sealing.
What do people think about this?
Is there any general guideline we could agree on, how to make use of file sealing consistently in future protocol extensions?