From: "Eregon (Benoit Daloze)" Date: 2022-01-09T13:41:50+00:00 Subject: [ruby-core:107015] [Ruby master Bug#18465] Make `IO#write` atomic. Issue #18465 has been updated by Eregon (Benoit Daloze). Ah and in either case the IO scheduler should either receive the already-concatenated string, or all strings to write together in a single hook call. Calling the write hook for each argument is of course broken. ---------------------------------------- Bug #18465: Make `IO#write` atomic. https://bugs.ruby-lang.org/issues/18465#change-95848 * 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: