Post · bonfire.cafe

Post

stdio sucks but also not having a way to read from an fd into a fixed size buffer in a way that is guaranteed to not be interrupted sucks (short reads for EOF is obv fine, EINTR that eats me)

i could write my own thing for that or use a library ig but don't want to, it should be there

wait wait wait -- i went to read the signal manpage and posix docs again, and if i got it right, if signals handlers are not installed (so, default behaviour or ignored), or installed with SA_RESTART, most syscalls will not be interrupted with EINTR (including read)

so if i just, install handlers with SA_RESTART, i don't have to deal with looping short-reads/EINTR at all -- and only if i'm writing a library i'd have to choose between propagating an EINTR, or not and either loop-read or mask signals temporarily

and lastly if i have an event loop, i can also mask all signals and unmask what i need only during ppoll() (though unsure why i'd do this over just installing handlers with SA_RESTART)

RE: https://social.vlhl.dev/objects/c59887aa-8b55-4c6d-bd92-b51fde5e7252

Cassandrich

@dalias@hachyderm.io replied · 10 hours ago

@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.

Cassandrich

@dalias@hachyderm.io replied · 9 hours ago

@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.

Cassandrich

@dalias@hachyderm.io replied · 9 hours ago

@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.

d@nny disc@ mc²

@hipsterelectron@circumstances.run replied · 9 hours ago

@dalias @navi my kingdom for more atomicity guarantees. we are still banging rocks together in my view. FUSE and io_uring are getting closer to the ideal case and getdents atomicity is like a cheat code

d@nny disc@ mc²

@hipsterelectron@circumstances.run replied · 9 hours ago

@dalias @navi i firmly and fervently agree with @zwol's proposal to investigate locking protocols over the VFS layer

Cassandrich

@dalias@hachyderm.io replied · 9 hours ago

@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.

1+ more replies (not shown)

d@nny disc@ mc²

@hipsterelectron@circumstances.run replied · 9 hours ago

@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.

1 more replies (not shown)

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances

Bonfire social · 1.0.2-alpha.7 no JS en

Automatic federation enabled