From: "ioquatix (Samuel Williams)" Date: 2022-01-13T05:48:45+00:00 Subject: [ruby-core:107094] [Ruby master Bug#18465] Make `IO#write` atomic. Issue #18465 has been updated by ioquatix (Samuel Williams). I would personally like to simplify `IO` implementation but I'm not sure if major refactor is acceptable especially given the chance for performance regressions. You are right, if someone holds a lock when writing to `stdout` or `stderr` it in theory could be a problem if the scheduler also tries to re-enter the locked segment. That being said, logging to IO from the scheduler requires an incredibly careful implementation as in theory you can already hold a lock while entering into the scheduler in the current implementation, IIRC. I'd need to check. ---------------------------------------- Bug #18465: Make `IO#write` atomic. https://bugs.ruby-lang.org/issues/18465#change-95940 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Right now, `IO#write` including everything that calls it including `IO#puts`, has a poorly specified behaviour w.r.t. other fibers/threads that call `IO#write` at the same time. Internally, we have a write lock, however it's only used to lock against individual writes rather than the whole operation. From a user point of view, there is some kind of atomicity, but it's not clearly defined and depends on many factors, e.g. whether `write` or `writev` is used internally. We propose to make `IO#write` an atomic operation, that is, `IO#write` on a synchronous/buffered IO will always perform the write operation using a lock around the entire operation. In theory, this should actually be more efficient than the current approach which may acquire and release the lock several times per operation, however in practice I'm sure it's almost unnoticeable. Where it does matter, is when interleaved operations invoke the fiber scheduler. By using a single lock around the entire operation, rather than one or more locks around the system calls, the entire operation is more predictable and behaves more robustly. -- https://bugs.ruby-lang.org/ Unsubscribe: