4 ms·

> No one would (should!) ever consider writing a webservice in C++, simply because it's unsafe to do so That's a pretty bold statements. By the same account, y

by mtanski 11y ago

> No one would (should!) ever consider writing a webservice in C++, simply because it's unsafe to do so That's a pretty bold statements. By the same account, you should not write a webservice in rust because it's unsafe. One example is Rust's treatment of OOM cases. Today, if you run into OOM Rust will panic. Technically, you can have it call a oom handler, but you cannot call many common function in the handler since they allocate memory, so it's not super useful. Here's the bug, https://github.com/rust-lang/rust/issues/27335 https://github.com/rust-lang/rust/issues/27335 . And, here is the original one https://github.com/rust-lang/rust/issues/14674 https://github.com/rust-lang/rust/issues/14674 . (Side note: I find the habit of closing bugs and reopening new ones kind of annoying, since it's hard to track how long it's been know / around). I imagine as a malicious client you could try to DOS an application by 1. forming a message that will cause the application to allocate a lot of memory (as temporary buffers). 2. Send a lot of messages causing pressure on the memory subsystem. You can of course try to not have these issues in your application, but Rust doesn't explicitly save you from the, On the other hand in C application, you can try to close the offending client's connection and in C++ if you get a bad_alloc (and you deal with it) you'll end up unwinding your stack (and free enough memory to continue on). C++ makes it even easier to handle it at the top level and let RAI take care of the rest. Yes, in Linux you can die in the system oom case. But, 1. you can turn that off (and you should at least on some systems), 2. depending on your over commit policy you'll get an error instead of OOM if you allocate in a too big chunk. I personal like Rust and I'd like to see it succeed. But I think the Rust marketing is getting away from what Rust is able to do in it's current incarnation (1.2). Simply, in it's current incarnation there's lot's of unsolved problems (big and small). So please stop making outlandish claims.

yokohummer7 11y ago
You say like C/C++ applications are particularly more resilient to OOM situations. That hasn't been my experience. You can deal with OOM in C/C++, but that doesn't mean it is quite viable. Even popular C libraries just abort when memory allocation failed. Regarding C++, is there really a code that even tries to capture `bad_alloc`? If so, did they test the various OOM situations that the program may encounter? I highly doubt it. I don't think that the "just panic" strategy used by Rust is pretty. It is mediocre at best. But I also don't think the way C/C++ handle OOM is great. They produce similar results in practice.
- mtanski 11y ago
  C libraries are worse, esp. the desktop focused ones (glib and all of gnome). Network focused libraries tend to be better (lib libevent / libev), and you see people send patches to fix OOM cases since enough people disable over commit / don't run Linux. In my experience C++ libraries tend to do better because of culture using RAI for everything. And the C++ servers I've worked with most of them had a std::exception handler some where near the top of connection / request handler and deal with it fine. And over the years, the bad_allocs helped us deal with some dumb (but not malicious) clients without going down. In one case the client was essentially causing a multi GB buffering window to happen. I'd be curious if anybody at fb could share their experiences since it seams like they building a lot of stuff using their C++ folly / proxygen libraries.
  - yokohummer7 11y ago
    That's interesting, it seems that I'm biased because I've primarily seen desktop-ish libraries. Regarding your usage of `bad_alloc`, I think relaxing the current behavior of aborting will help implement such a behavior. Long-running Rust applications should be resilient to panics anyways, so request handler may regard OOM as just like many other panicking situations. But I have no idea how it would be hard to change Rust's OOM handler to panic. Currently it just aborts.
    - mtanski 11y ago
      While I think this is an important problem to solve, it's not lost on me that this isn't an easy problem to solve. It's complicated further by design decisions like no stack unwinding and current behavior. I'm not sure they can change the current behavior without having a backwards incompatible change. It's also not a unique problem. The Linux guys have been working better handling OOMs in the kernel. There's been some interesting discussions in the last year how to guarantee forward progress in filesystem transactions in the face of OOMs (in the middle of transactions).
      - pcwalton 11y ago
TheHydroImpulse 11y ago
When one says unsafe or safe, it's primarily about type safety and more so memory safety, so it depends if you consider OOM a violation of memory safety. If you don't have a hard limit in terms of your buffer or memory allocations (and have an unlimited upper-bound) you'll be in trouble sooner or later. I'd argue that it would be a far more robust principle to institute an upper-bound than trying to catch OOM errors.
- mtanski 11y ago
  Rust's goals are both type and memory safety. I consider an OOM with a panic/abort a memory safety issues. Linux also does these kinds of things to your process, but there at least you can opt out of it. I agree with you, in the real world you need some kind of well tuned upper limits above which you apply back pressure / start dropping connections. But in the absence of this the runtime should try to make every possible attempt at forward progress (even if we're just limping along).
  - MichaelGG 11y ago
    How is OOM unsafe? By that definition, all languages are unsafe. And note, this is waving over the real safety issues that C/C++ has, which allows small bugs to turn into remote shells.
  - pcwalton 11y ago
    It's not a memory safety issue any more than any other kind of abort is. If it were, abort would be marked unsafe. > But in the absence of this the runtime should try to make every possible attempt at forward progress (even if we're just limping along). So what is your proposal?
sillysill 11y ago
I'm wondering how this is honestly seen in production, especially on Linux since malloc() never fails, how does rust detect its OOM ?
tinco 11y ago
It's not a very bold statement. I bet Strousup would back me up on it, and if not he would add slight nuance. The basic thought process for choosing C++ is very simple: Can I do this in any other language, if yes, choose one of those languages. The cool thing about Rust is that it covers a selection of problems where normally the answer would be 'no'. I totally believe you that there's still problems where the answer is still no, but I don't think a webservice is going to be it.

by mtanski 11y ago

yokohummer7 11y ago

You say like C/C++ applications are particularly more resilient to OOM situations. That hasn't been my experience. You can deal with OOM in C/C++, but that doesn't mean it is quite viable. Even popular C libraries just abort when memory allocation failed. Regarding C++, is there really a code that even tries to capture `bad_alloc`? If so, did they test the various OOM situations that the program may encounter? I highly doubt it. I don't think that the "just panic" strategy used by Rust is pretty. It is mediocre at best. But I also don't think the way C/C++ handle OOM is great. They produce similar results in practice.

mtanski 11y ago
C libraries are worse, esp. the desktop focused ones (glib and all of gnome). Network focused libraries tend to be better (lib libevent / libev), and you see people send patches to fix OOM cases since enough people disable over commit / don't run Linux. In my experience C++ libraries tend to do better because of culture using RAI for everything. And the C++ servers I've worked with most of them had a std::exception handler some where near the top of connection / request handler and deal with it fine. And over the years, the bad_allocs helped us deal with some dumb (but not malicious) clients without going down. In one case the client was essentially causing a multi GB buffering window to happen. I'd be curious if anybody at fb could share their experiences since it seams like they building a lot of stuff using their C++ folly / proxygen libraries.
- yokohummer7 11y ago
  That's interesting, it seems that I'm biased because I've primarily seen desktop-ish libraries. Regarding your usage of `bad_alloc`, I think relaxing the current behavior of aborting will help implement such a behavior. Long-running Rust applications should be resilient to panics anyways, so request handler may regard OOM as just like many other panicking situations. But I have no idea how it would be hard to change Rust's OOM handler to panic. Currently it just aborts.
  - mtanski 11y ago
    While I think this is an important problem to solve, it's not lost on me that this isn't an easy problem to solve. It's complicated further by design decisions like no stack unwinding and current behavior. I'm not sure they can change the current behavior without having a backwards incompatible change. It's also not a unique problem. The Linux guys have been working better handling OOMs in the kernel. There's been some interesting discussions in the last year how to guarantee forward progress in filesystem transactions in the face of OOMs (in the middle of transactions).
    - pcwalton 11y ago

TheHydroImpulse 11y ago

When one says unsafe or safe, it's primarily about type safety and more so memory safety, so it depends if you consider OOM a violation of memory safety. If you don't have a hard limit in terms of your buffer or memory allocations (and have an unlimited upper-bound) you'll be in trouble sooner or later. I'd argue that it would be a far more robust principle to institute an upper-bound than trying to catch OOM errors.

mtanski 11y ago
Rust's goals are both type and memory safety. I consider an OOM with a panic/abort a memory safety issues. Linux also does these kinds of things to your process, but there at least you can opt out of it. I agree with you, in the real world you need some kind of well tuned upper limits above which you apply back pressure / start dropping connections. But in the absence of this the runtime should try to make every possible attempt at forward progress (even if we're just limping along).
- MichaelGG 11y ago
  How is OOM unsafe? By that definition, all languages are unsafe. And note, this is waving over the real safety issues that C/C++ has, which allows small bugs to turn into remote shells.
- pcwalton 11y ago
  It's not a memory safety issue any more than any other kind of abort is. If it were, abort would be marked unsafe. > But in the absence of this the runtime should try to make every possible attempt at forward progress (even if we're just limping along). So what is your proposal?

sillysill 11y ago

I'm wondering how this is honestly seen in production, especially on Linux since malloc() never fails, how does rust detect its OOM ?

tinco 11y ago

It's not a very bold statement. I bet Strousup would back me up on it, and if not he would add slight nuance. The basic thought process for choosing C++ is very simple: Can I do this in any other language, if yes, choose one of those languages. The cool thing about Rust is that it covers a selection of problems where normally the answer would be 'no'. I totally believe you that there's still problems where the answer is still no, but I don't think a webservice is going to be it.