[#113407] [Ruby master Feature#19630] [RFC] Deprecate `Kernel.open("|command-here")` due to frequent security issues — "postmodern (Hal Brodigan) via ruby-core" <ruby-core@...>

Issue #19630 has been reported by postmodern (Hal Brodigan).

19 messages 2023/05/05

[#113430] [Ruby master Feature#19633] Allow passing block to `Kernel#autoload` as alternative to second `filename` argument — "shioyama (Chris Salzberg) via ruby-core" <ruby-core@...>

Issue #19633 has been reported by shioyama (Chris Salzberg).

16 messages 2023/05/09

[#113489] [Ruby master Bug#19642] Remove vectored read/write from `io.c`. — "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...>

Issue #19642 has been reported by ioquatix (Samuel Williams).

10 messages 2023/05/15

[#113498] [Ruby master Feature#19644] Module::current to complement Module::nesting — "bughit (bug hit) via ruby-core" <ruby-core@...>

Issue #19644 has been reported by bughit (bug hit).

12 messages 2023/05/16

[#113517] [Ruby master Misc#19679] Migrate Wiki from bugs.ruby-lang.org to ruby/ruby GitHub repository — "jemmai (Jemma Issroff) via ruby-core" <ruby-core@...>

Issue #19679 has been reported by jemmai (Jemma Issroff).

11 messages 2023/05/18

[#113529] [Ruby master Bug#19681] The final classpath of partially named modules is sometimes inconsistent once permanently named — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>

Issue #19681 has been reported by byroot (Jean Boussier).

34 messages 2023/05/19

[#113538] [Ruby master Feature#19682] ability to get a reference to the "default definee" — "bughit (bug hit) via ruby-core" <ruby-core@...>

Issue #19682 has been reported by bughit (bug hit).

28 messages 2023/05/19

[#113601] [Ruby master Bug#19687] Should a development version of the standard library be included in ruby/ruby? — "jaruga (Jun Aruga) via ruby-core" <ruby-core@...>

Issue #19687 has been reported by jaruga (Jun Aruga).

9 messages 2023/05/23

[#113632] [Ruby master Bug#19691] Case insensitive file systems, require filename casing — "MSP-Greg (Greg L) via ruby-core" <ruby-core@...>

Issue #19691 has been reported by MSP-Greg (Greg L).

7 messages 2023/05/24

[#113656] [Ruby master Misc#19693] Data initialization is significantly slower than Struct — janosch-x via ruby-core <ruby-core@...>

Issue #19693 has been reported by janosch-x (Janosch M=FCller).

13 messages 2023/05/25

[#113660] [Ruby master Feature#19694] Add Regexp#timeout= setter — "aharpole (Aaron Harpole) via ruby-core" <ruby-core@...>

Issue #19694 has been reported by aharpole (Aaron Harpole).

15 messages 2023/05/25

[#113676] [Ruby master Bug#19697] Resolv::DNS resolution for international domains fails with "Encoding::CompatibilityError: incompatible character encodings: UTF-8 and ASCII-8BIT" — "clairity (claire c) via ruby-core" <ruby-core@...>

SXNzdWUgIzE5Njk3IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGNsYWlyaXR5IChjbGFpcmUgYykuDQ0K

6 messages 2023/05/27

[ruby-core:113525] [Ruby master Feature#19642] Remove vectored read/write from `io.c`.

From: "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...>
Date: 2023-05-19 01:33:15 UTC
List: ruby-core #113525
Issue #19642 has been updated by ioquatix (Samuel Williams).


Thanks Nakamura-san for your feedback.

According to POSIX:

> Atomic/non-atomic: A write is atomic if the whole amount written in one operation is not interleaved with data from any other process. This is useful when there are multiple writers sending data to a single reader. Applications need to know how large a write request can be expected to be performed atomically. This maximum is called {PIPE_BUF}. This volume of IEEE Std 1003.1-2001 does not say whether write requests for more than {PIPE_BUF} bytes are atomic, but requires that writes of {PIPE_BUF} or fewer bytes shall be atomic.

I assume since `writev` is defined in terms of `write`, that `writev` of total size <= `PIPE_BUF` will be atomic. It is not defined what happens when the size is bigger than `PIPE_BUF`, but we can assume it is non-atomic.

Since we already have a write lock in `IO`, writes should be atomic at the Ruby IO level. But not at the kernel level and not between processes that share the same pipes.

```
irb(main):001:0> $stderr.sync
=> true
irb(main):002:0> $stdout.sync
=> true
```

It looks like `$stdout` and `$stderr` are both buffered internally.

I think Ruby should guarantee buffered writes will be atomic up to PIPE_BUF.

Unbuffered writes should have no atomicity guarantees.

If it's not documented, maybe we can consider adding that.

----------------------------------------
Feature #19642: Remove vectored read/write from `io.c`.
https://bugs.ruby-lang.org/issues/19642#change-103151

* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Assignee: ioquatix (Samuel Williams)
----------------------------------------
https://github.com/socketry/async/issues/228#issuecomment-1546789910 is a comment from the kernel developer who tells us that `writev` is always worse than `write` system call.

A large amount of complexity in `io.c` comes from optional support from `writev`.

So, I'd like to remove support for `writev`.

I may try to measure the performance before/after. However it may not show much difference, except that the implementation in `io.c` can be much simpler.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

In This Thread