@zwol @dalias @navi isn't it like a well-known meme that every database designer eventually has to start disabling lots of helpful mechanisms from the kernel?
for me, i very specifically want to write code working at the VFS level and then also take over requests to the block layer, since the build tool has much more context for that—e.g. whether a file output is "writethrough" or will be immediately requested again
@navi You're mostly correct. EINTR is only a possibility (except for a select few operations explicitly allowed to do it even with SA_RESTART) when you're using the broken legacy sysv-style signal handling without SA_RESTART.
There is *no correct usage* for non-restarting signal handlers, since any attempt to use them has race conditions (signal arrives between unmasking/checking and the making the blocking syscall, so the syscall still blocks forever) that can only be solved by hammering signals with exponential backoff to avoid execution time starvation.
As far as I'm concerned, outside of things that need to deal with them for conformance reasons (libc), it's completely acceptable to pretend non-SA_RESTART signals don't exist and that installing one is programmer-error.
@navi However, short reads/writes are always a possibility, for multiple reasons.
One is signals. Even non-interrupting signal handlers necessarily cut short an unfinished operation that has already had side effects (transferring some data, etc.) since there is nowhere for the partially-compete state to be kept across an unbounded number of possibly nested signal handling contexts.
@navi Short reads/writes can also happen in other contexts where cutting the operation short is necessary in order to honor some atomicity requirement (the shortened transfer can be atomic, but the full one would be observably non-atomic), where read/write respect some kind of message boundaries (like datagram sockets), etc.
There are a few major exceptions: writes to pipes not larger than PIPE_BUF are atomic (never short) and do not block if poll indicated writable status, and writes to datagram socket types likewise.
@hipsterelectron @navi @zwol There's so much that can go wrong trying to do this. I understand the desire to have it, but you create all sorts of vectors for userspace to block forward progress of kernelspace/other tasks unboundedly.
The design of unix fs semantics very intentionally evolved (in the sense of excluding additions that would preclude this) not to require that, because it's a bad thing.
@dalias @navi @zwol i have been spending the past week making a ring buffer because the entire rust community incredibly has never heard of backpressure and i have this atomic-friendly "token" protocol that attempts to minimize contention while giving clients access to the raw memory as opposed to imposing some sort of restrictions over it. importantly, it's possible to request a token, then not use the whole allocated space and return some of it for later.
