3 ms·

A sibling comment [1] points out that the kernel recently gained some RAII-like functionality. The typical alternative to RAII-based error handling in C tends

A sibling comment [1] points out that the kernel recently gained some RAII-like functionality. The typical alternative to RAII-based error handling in C tends to be goto statements. I'm sure those of us who have written C are used to writing goto statements in inverse order for their error handling -- and we've also made mistakes with them especially when there's a lot of branching paths (or at least I have). In comparison to that I personally appreciate RAII quite a lot. Even with arena allocation, it may make sense to have a struct be composed of some memory that's borrowed from the arena and some that's owned by the struct. That works exactly as you'd expect in Rust. [1] https://news.ycombinator.com/item?id=42291921 https://news.ycombinator.com/item?id=42291921

perching_aix 2y ago
This doesn't quite address what I wrote about specifically.
- sunshowers 2y ago
  I'm quite sympathetic to social effects of technical choices in general! You said: > The author's line of thought seems to be concerned with the social aspect of RAII in my reading though. Like how you can write memory-safe C if you're a "good C programmer" (meaning most people evidently won't), these considerations for RAII might be subtle enough that it justifies banning its use altogether (like using memory unsafe constructions is in safe Rust). In response I gave you a link which (if you follow it) says: * The "goto error" pattern is notorious for introducing subtle resource * leaks. It is tedious and error prone to add new resource acquisition * constraints into code paths that already have several unwind * conditions. The "cleanup" helpers enable the compiler to help with * this tedium and can aid in maintaining LIFO (last in first out) * unwind ordering to avoid unintentional leaks. So clearly this is about understanding that goto-based error handling doesn't really scale and adding RAII-like behavior to make it work better.
  - perching_aix 2y ago
    What you linked to / cite doesn't address what I was talking about either. I understand that you believe it does, so let me clarify why I think it doesn't. On the top level, you wrote: > I would imagine kernel developers working with Rust are quite aware of the downsides of RAII when it comes to large synchronous drops, and aware of arena allocation patterns. They are also likely aware of both arenas that run destructors on drop, and arenas that don't, and the relative merits of each. Thing is, I'm not nearly familiar enough on a low level with constructs like RAII - however, I think this is actually working in my advantage in this case. Because to me what you wrote reads like this: - RAII in certain scenarios should be avoided - those scenarios are mindware (and we just trust that kernel devs can and will recall it as appropriate) - arenas running destructors on drop in certain scenarios should be avoided - those scenarios are also mindware (and we just trust that kernel devs can and will recall it as appropriate) Crucially, none of this is about whether RAII is better than any alternative (relative value), but is about its properties (absolute value). This is also not incompatible with what the article says, in fact, I believe is what the article was sort of peddling inadvertently. And so my comment was about relating this to the memory management of C in principle. That the flow of the argument (I think) is similar. That the correctness is dependent on the programmer attention (and their correct usage of tooling), while also being high on the skill tree. Now, I understand if this comes off as an extremely unrevelatory discovery, or if you feel different about the likelihoods involved. But I found it fascinating, if not equally fearsome.
    - sunshowers 2y ago
      Thank you for clarifying! That's helpful. > - those scenarios are mindware (and we just trust that kernel devs can and will recall it as appropriate) Ah, I see. I don't think they're "mindware" so much as they're good targets for making data-driven decisions about. Unlike C memory safety which no amount of measurement or careful thinking can solve, the relative merits of RAII/direct allocations vs arena allocations can be determined case-by-case through running a profiler and trying out things. Rust doesn't really lock you in to one approach, especially at the scale of an individual device driver. I think there is space here for a more sophisticated critique of Rust, which is that trying out alternative strategies can take some effort and still deliver negative results. For example, I was recently doing some profiling on an application and found that deserializing Cargo's metadata format (and malloc within it) show up a bunch. Out of curiosity, I tried switching the cargo-metadata crate [1] to using zero-copy deserialization. It took a couple hours to do. The end result was around a 15% performance improvement in the deserialization process -- not nothing, but also not hugely impactful, and overshadowed by the act of generating and reading the JSON on Cargo's side. But negative results are still useful. [1] https://crates.io/crates/cargo_metadata https://crates.io/crates/cargo_metadata

perching_aix 2y ago

This doesn't quite address what I wrote about specifically.

sunshowers 2y ago
I'm quite sympathetic to social effects of technical choices in general! You said: > The author's line of thought seems to be concerned with the social aspect of RAII in my reading though. Like how you can write memory-safe C if you're a "good C programmer" (meaning most people evidently won't), these considerations for RAII might be subtle enough that it justifies banning its use altogether (like using memory unsafe constructions is in safe Rust). In response I gave you a link which (if you follow it) says: * The "goto error" pattern is notorious for introducing subtle resource * leaks. It is tedious and error prone to add new resource acquisition * constraints into code paths that already have several unwind * conditions. The "cleanup" helpers enable the compiler to help with * this tedium and can aid in maintaining LIFO (last in first out) * unwind ordering to avoid unintentional leaks. So clearly this is about understanding that goto-based error handling doesn't really scale and adding RAII-like behavior to make it work better.
- perching_aix 2y ago
  What you linked to / cite doesn't address what I was talking about either. I understand that you believe it does, so let me clarify why I think it doesn't. On the top level, you wrote: > I would imagine kernel developers working with Rust are quite aware of the downsides of RAII when it comes to large synchronous drops, and aware of arena allocation patterns. They are also likely aware of both arenas that run destructors on drop, and arenas that don't, and the relative merits of each. Thing is, I'm not nearly familiar enough on a low level with constructs like RAII - however, I think this is actually working in my advantage in this case. Because to me what you wrote reads like this: - RAII in certain scenarios should be avoided - those scenarios are mindware (and we just trust that kernel devs can and will recall it as appropriate) - arenas running destructors on drop in certain scenarios should be avoided - those scenarios are also mindware (and we just trust that kernel devs can and will recall it as appropriate) Crucially, none of this is about whether RAII is better than any alternative (relative value), but is about its properties (absolute value). This is also not incompatible with what the article says, in fact, I believe is what the article was sort of peddling inadvertently. And so my comment was about relating this to the memory management of C in principle. That the flow of the argument (I think) is similar. That the correctness is dependent on the programmer attention (and their correct usage of tooling), while also being high on the skill tree. Now, I understand if this comes off as an extremely unrevelatory discovery, or if you feel different about the likelihoods involved. But I found it fascinating, if not equally fearsome.
  - sunshowers 2y ago
    Thank you for clarifying! That's helpful. > - those scenarios are mindware (and we just trust that kernel devs can and will recall it as appropriate) Ah, I see. I don't think they're "mindware" so much as they're good targets for making data-driven decisions about. Unlike C memory safety which no amount of measurement or careful thinking can solve, the relative merits of RAII/direct allocations vs arena allocations can be determined case-by-case through running a profiler and trying out things. Rust doesn't really lock you in to one approach, especially at the scale of an individual device driver. I think there is space here for a more sophisticated critique of Rust, which is that trying out alternative strategies can take some effort and still deliver negative results. For example, I was recently doing some profiling on an application and found that deserializing Cargo's metadata format (and malloc within it) show up a bunch. Out of curiosity, I tried switching the cargo-metadata crate [1] to using zero-copy deserialization. It took a couple hours to do. The end result was around a 15% performance improvement in the deserialization process -- not nothing, but also not hugely impactful, and overshadowed by the act of generating and reading the JSON on Cargo's side. But negative results are still useful. [1] https://crates.io/crates/cargo_metadata https://crates.io/crates/cargo_metadata