3 ms·

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

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
    Thing is, my impression is that running a profiler can get quite convoluted. I'm aware for example of different types of profilers / profiling techniques, but not in detail. I also know that I wouldn't pull out a profiler, unless I was experiencing unacceptable performance, which may not happen on my (or the reviewers') end at all. ... which again rings really similar to the memory management story in C (in my head anyways). You can use tooling, and the tooling does help, but certain tooling only helps in certain scenarios, and if you didn't bother to use the tooling for whatever reason, you're hosed, and you won't find out until potentially much later or even too late. What I'm essentially getting at is that Rust doesn't provide guarantees that'd ensure the correct employment of RAII or arenas (according to both you and the article at least), meaning their pitfalls manifesting exist somewhere on this range from possible to likely, and then depending on who you ask, the answer may be different. The article author appears to be of the opinion that this probability is closer to likely, while you - if I read it correctly - think it is closer to the other end of the spectrum. But another interpretation of the article is that the author is just remarking that it is a possibility now at all, and that that makes it a bad thing, regardless of likelihood. So ultimately, my point was to try and get engagement on this idea specifically rather than debating the likelihood itself, especially considering I stand no chance at appropriately gauging that likelihood myself.

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
  Thing is, my impression is that running a profiler can get quite convoluted. I'm aware for example of different types of profilers / profiling techniques, but not in detail. I also know that I wouldn't pull out a profiler, unless I was experiencing unacceptable performance, which may not happen on my (or the reviewers') end at all. ... which again rings really similar to the memory management story in C (in my head anyways). You can use tooling, and the tooling does help, but certain tooling only helps in certain scenarios, and if you didn't bother to use the tooling for whatever reason, you're hosed, and you won't find out until potentially much later or even too late. What I'm essentially getting at is that Rust doesn't provide guarantees that'd ensure the correct employment of RAII or arenas (according to both you and the article at least), meaning their pitfalls manifesting exist somewhere on this range from possible to likely, and then depending on who you ask, the answer may be different. The article author appears to be of the opinion that this probability is closer to likely, while you - if I read it correctly - think it is closer to the other end of the spectrum. But another interpretation of the article is that the author is just remarking that it is a possibility now at all, and that that makes it a bad thing, regardless of likelihood. So ultimately, my point was to try and get engagement on this idea specifically rather than debating the likelihood itself, especially considering I stand no chance at appropriately gauging that likelihood myself.