28 ms·

It's not about memory safety, as you might assume from the title. There's no soundness bug involved.

ethegwo 2y ago
Rust not only provides memory safety, it also promises at least I/O safety in the future: https://rust-lang.github.io/rfcs/3128-io-safety.html https://rust-lang.github.io/rfcs/3128-io-safety.html
- the8472 2y ago
  Leaking file descriptors is safe, at least as far as the IO-safety RFC defines it. It's just a regular bug.
- fallingsquirrel 2y ago
  Resource leaks have nothing to do with safety. That's true both for memory safety and i/o safety. See for yourself with `mem::forget(File::open(...)?)`
  - ekidd 2y ago
    Yeah, "safe Rust" is officially allowed to leak memory and other resources. - The easiest way to do this is mem::forget, a safe function which exists to leak memory deliberately. - The most common real way to leak memory is to create a loop using the Rc<T> or Arc<T> reference count types. I've never seen this in any of my company's Rust code, but we don't write our own cyclic data structures, either. This is either a big deal to you, or a complete non-issue, depending on your program architecture. Basically, "safe Rust" aims to protect you from memory corruption, undefined behavior, and data races between threads. It does not protect you from leaks, other kinds of race conditions, or (obviously) logic bugs.
  - chubot 2y ago
    Yeah the article is giving what looks like a bad definition: According to: https://rust-lang.github.io/rfcs/3128-io-safety.html https://rust-lang.github.io/rfcs/3128-io-safety.html Rust’s standard library almost provides I/O safety, a guarantee that if one part of a program holds a raw handle privately, other parts cannot access it. According to the article: I/O Safety: Ensuring that accepted TCP streams are properly closed without leaking connections. These are not the same definition. As I've mentioned several times [1], in Rust, the word "safety" is being abused to the point of causing confusion, and it looks like this is another instance of that. [1] https://news.ycombinator.com/item?id=31726723 https://news.ycombinator.com/item?id=31726723
    - ethegwo 2y ago
      Thank you! I will update the post and fix it.
- morning-coffee 2y ago
  Where do you conclude "Rust promises I/O safety in the future"? An RFC is not a promise to do anything... it may represent a desire... a possibility, but you taking that leap and implying a promise is a flagrant misrepresentation. Now let's take "the future" part... you seem to be impugning Async Rust for something it's not even purported to do in the present. What's the point of this? You found a bug in monoio it seems... I don't see the argument you've presented as supporting the premise that "Async Rust is not safe".
- remram 2y ago
  That doesn't mean the Rust project promise no one will write a library that is not safe... The title of this submission is aimed specifically at "Async Rust", ie the language. The reality is that one third-party library with 4k stars on GitHub and 0.2.4 version number has a non-memory-unsafe leak. I'd say the title is a full-on lie.

Rust not only provides memory safety, it also promises at least I/O safety in the future: https://rust-lang.github.io/rfcs/3128-io-safety.html https://rust-lang.github.io/rfcs/3128-io-safety.html

the8472 2y ago
Leaking file descriptors is safe, at least as far as the IO-safety RFC defines it. It's just a regular bug.
fallingsquirrel 2y ago
Resource leaks have nothing to do with safety. That's true both for memory safety and i/o safety. See for yourself with `mem::forget(File::open(...)?)`
- ekidd 2y ago
  Yeah, "safe Rust" is officially allowed to leak memory and other resources. - The easiest way to do this is mem::forget, a safe function which exists to leak memory deliberately. - The most common real way to leak memory is to create a loop using the Rc<T> or Arc<T> reference count types. I've never seen this in any of my company's Rust code, but we don't write our own cyclic data structures, either. This is either a big deal to you, or a complete non-issue, depending on your program architecture. Basically, "safe Rust" aims to protect you from memory corruption, undefined behavior, and data races between threads. It does not protect you from leaks, other kinds of race conditions, or (obviously) logic bugs.
- chubot 2y ago
  Yeah the article is giving what looks like a bad definition: According to: https://rust-lang.github.io/rfcs/3128-io-safety.html https://rust-lang.github.io/rfcs/3128-io-safety.html Rust’s standard library almost provides I/O safety, a guarantee that if one part of a program holds a raw handle privately, other parts cannot access it. According to the article: I/O Safety: Ensuring that accepted TCP streams are properly closed without leaking connections. These are not the same definition. As I've mentioned several times [1], in Rust, the word "safety" is being abused to the point of causing confusion, and it looks like this is another instance of that. [1] https://news.ycombinator.com/item?id=31726723 https://news.ycombinator.com/item?id=31726723
  - ethegwo 2y ago
    Thank you! I will update the post and fix it.
morning-coffee 2y ago
Where do you conclude "Rust promises I/O safety in the future"? An RFC is not a promise to do anything... it may represent a desire... a possibility, but you taking that leap and implying a promise is a flagrant misrepresentation. Now let's take "the future" part... you seem to be impugning Async Rust for something it's not even purported to do in the present. What's the point of this? You found a bug in monoio it seems... I don't see the argument you've presented as supporting the premise that "Async Rust is not safe".
remram 2y ago
That doesn't mean the Rust project promise no one will write a library that is not safe... The title of this submission is aimed specifically at "Async Rust", ie the language. The reality is that one third-party library with 4k stars on GitHub and 0.2.4 version number has a non-memory-unsafe leak. I'd say the title is a full-on lie.