5 ms·

Comparing with the current Cargo default [1]: • `panic = "abort"` means that any panic terminates the program. This is not always desirable because you may wan

Comparing with the current Cargo default [1]: • `panic = "abort"` means that any panic terminates the program. This is not always desirable because you may want to catch and recover from panics, particularly in long-running servers. • `strip = true` means that anything depending on DWARF would no longer work. Backtraces won't work, but also unwinding will no longer work (so this is disastrous if you haven't set `panic` above). The actual proposal has `strip = "debuginfo"` instead, so unwinding will work while backtraces won't. • `codegen-units = 1` is the number of concurrent compilation jobs (cgu) in the LLVM codegen phase. A single cgu will significantly increase the compilation time, while allowing a bit more optimization. Otherwise this is okay. • `lto = true` enables Rust-specific link-time optimizations across crates. The actual benefit depends on the set of crates linked, but it is significantly slower that many large enough projects wouldn't want it. It does benefit small programs like the "Hello, world" program the most though. • `opt-level = "z"` is same to C/C++ `-Oz` and the same pros and cons apply. [1] https://doc.rust-lang.org/cargo/reference/profiles.html#release https://doc.rust-lang.org/cargo/reference/profiles.html#rele...

flohofwoe 3y ago
All makes sense, but I don't agree with: > This is not always desirable because you may want to catch and recover from panics, particularly in long-running servers. IMHO a panic implies that execution cannot continue under any circumstances, and even any attempts for a graceful shutdown might be futile (if recovery is possible it shouldn't be a panic but done through regular error handling). For a server process the best reaction to a panic would mean abort and clean restart. > A single cgu will significantly increase the compilation time, while allowing a bit more optimization. Increased build time is acceptable for release mode IMHO.
- robinsonrc 3y ago
  I remember my disappointment when I found out panics could be “caught” and that I was still living in the world of exceptions
  - josephg 3y ago
    Oh no, I didn't know this. I'm adding panic = "abort" to all my projects. If I wanted exceptions I wouldn't be using rust.
    - lifthrasiir 3y ago
      That's actually not too bad if you know you don't need to recover from panic. I kinda hope that `panic = "abort"` is indeed default unless overridden by dependencies, say, tokio...
    - formerly_proven 3y ago
      You can catch them locally (https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html) or with a global exception handler (https://doc.rust-lang.org/std/panic/fn.set_hook.html https://doc.rust-lang.org/std/panic/fn.set_hook.html)
  - kibwen 3y ago
    Panics have to be catchable because it's undefined behavior for Rust to unwind through C code, so a Rust library that exposes a C API has to stop panics at the FFI boundary and propagate errors in a C-compatible way. It's not "catching" in the Java sense; nobody is using catch_panic to implement resumable error-handling.
  - IshKebab 3y ago
    You aren't. They're only caught in special cases, e.g. if a thread panics and you want to propagate that to other threads, to catch panics in unit tests, to avoid unwinding across FFI, etc. You shouldn't use them as a general exception mechanism. They aren't the same, even if under the hood they both use stack unwinding.
    - vacuity 3y ago
      Naively, what is the difference between panics and exceptions? Is it the philosophy on when/how to use them?
- tonyedgecombe 3y ago
  >For a server process the best reaction to a panic would mean abort and clean restart. I suppose you could have a panic in one thread whilst others are still running fine. You may just want to shut those other threads down gracefully.
- lifthrasiir 3y ago
  > IMHO a panic implies that execution cannot continue under any circumstances, and even any attempts for a graceful shutdown might be futile (if recovery is possible it shouldn't be a panic but done through regular error handling). Rust panic is just a C++ exception in its implementation, and not every C++ programmer would terminate a process when an exception is thrown. Of course Rust panic is more resillient because Rust provides a memory safety and the logic error can be reasonably bounded as a result. > Increased build time is acceptable for release mode IMHO. I think the slowest possible configuration is at least 3x slower than the default, and that's too slow to be acceptable for most people. But you can always tune them up if you want---please note that this issue is all about defaults.
- pornel 3y ago
  > For a server process the best reaction to a panic would mean abort and clean restart. That's often infeasible, and creates a major DoS/reliability problem. The server may be processing hundreds of different requests at the same time, and panic=abort will kill all of them. That creates a visible failure to other unrelated clients of the server, not just the offending request. If you try to fix that and retry aborted requests, you'll retry the panic-inducing request and cause another failure (and it'll take several restarts to bisect out the offending request). Plus a restart may be costly, require loading data, warming up caches, etc. It's just way cheaper to catch a panic and return 500 to the offending request. Rust guarantees to panic before anything terrible memory-corrupting happens. Even if you don't trust it and would prefer to restart anyway, you have an option to gracefully hand over the traffic before the restart.

flohofwoe 3y ago

All makes sense, but I don't agree with: > This is not always desirable because you may want to catch and recover from panics, particularly in long-running servers. IMHO a panic implies that execution cannot continue under any circumstances, and even any attempts for a graceful shutdown might be futile (if recovery is possible it shouldn't be a panic but done through regular error handling). For a server process the best reaction to a panic would mean abort and clean restart. > A single cgu will significantly increase the compilation time, while allowing a bit more optimization. Increased build time is acceptable for release mode IMHO.

robinsonrc 3y ago
I remember my disappointment when I found out panics could be “caught” and that I was still living in the world of exceptions
- josephg 3y ago
  Oh no, I didn't know this. I'm adding panic = "abort" to all my projects. If I wanted exceptions I wouldn't be using rust.
  - lifthrasiir 3y ago
    That's actually not too bad if you know you don't need to recover from panic. I kinda hope that `panic = "abort"` is indeed default unless overridden by dependencies, say, tokio...
  - formerly_proven 3y ago
    You can catch them locally (https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html) or with a global exception handler (https://doc.rust-lang.org/std/panic/fn.set_hook.html https://doc.rust-lang.org/std/panic/fn.set_hook.html)
- kibwen 3y ago
  Panics have to be catchable because it's undefined behavior for Rust to unwind through C code, so a Rust library that exposes a C API has to stop panics at the FFI boundary and propagate errors in a C-compatible way. It's not "catching" in the Java sense; nobody is using catch_panic to implement resumable error-handling.
- IshKebab 3y ago
  You aren't. They're only caught in special cases, e.g. if a thread panics and you want to propagate that to other threads, to catch panics in unit tests, to avoid unwinding across FFI, etc. You shouldn't use them as a general exception mechanism. They aren't the same, even if under the hood they both use stack unwinding.
  - vacuity 3y ago
    Naively, what is the difference between panics and exceptions? Is it the philosophy on when/how to use them?
tonyedgecombe 3y ago
>For a server process the best reaction to a panic would mean abort and clean restart. I suppose you could have a panic in one thread whilst others are still running fine. You may just want to shut those other threads down gracefully.
lifthrasiir 3y ago
> IMHO a panic implies that execution cannot continue under any circumstances, and even any attempts for a graceful shutdown might be futile (if recovery is possible it shouldn't be a panic but done through regular error handling). Rust panic is just a C++ exception in its implementation, and not every C++ programmer would terminate a process when an exception is thrown. Of course Rust panic is more resillient because Rust provides a memory safety and the logic error can be reasonably bounded as a result. > Increased build time is acceptable for release mode IMHO. I think the slowest possible configuration is at least 3x slower than the default, and that's too slow to be acceptable for most people. But you can always tune them up if you want---please note that this issue is all about defaults.
pornel 3y ago
> For a server process the best reaction to a panic would mean abort and clean restart. That's often infeasible, and creates a major DoS/reliability problem. The server may be processing hundreds of different requests at the same time, and panic=abort will kill all of them. That creates a visible failure to other unrelated clients of the server, not just the offending request. If you try to fix that and retry aborted requests, you'll retry the panic-inducing request and cause another failure (and it'll take several restarts to bisect out the offending request). Plus a restart may be costly, require loading data, warming up caches, etc. It's just way cheaper to catch a panic and return 500 to the offending request. Rust guarantees to panic before anything terrible memory-corrupting happens. Even if you don't trust it and would prefer to restart anyway, you have an option to gracefully hand over the traffic before the restart.