Ah, no, if using `panic::recover` then it wouldn't translate to a crash (I believe) as it's just normal execution. If you want a panic in Rust to translate to an abort of the entire process, however, then you've got two options.
On one hand you could use the custom panic hook support I mentioned above to install a hook that aborts the process. That way it would prevent reaching the machinery that actually throws an exception in Rust to be caught. An alternative is outlined in RFC 1513 [1] which is to configure compilations to always trigger an abort on panic instead of doing it via a roundabout method. Does that make sense? [1]: https://github.com/rust-lang/rfcs/pull/1513 On Tue, Mar 22, 2016 at 10:06 AM, Bobby Holley <bobbyhol...@gmail.com> wrote: > Does this mean that the default behavior in the main-thread FFI case is to > abort the process in a way that invokes the crash reporter? Because I think > that (along with zero-overhead) what Henri (and I) want. > > On Tue, Mar 22, 2016 at 9:45 AM, <acrich...@mozilla.com> wrote: > > > Hello! I do agree it is indeed bad to spawn a new thread for all calls > > into Rust :). You likely don't want a custom panic handler [1], however, > as > > those are actually more appropriately called "hooks" (just renamed [2]). > > > > Instead, the `std::panic::recover` function [3] is what you'll want for > > the FFI use case. This is essentially a "catch" block which will prevent > > the panic from aborting the process and allow you to handle the case that > > the code panicked properly (for example poisoning state, propagating the > > error to C++, etc). This way you avoid spawning a thread for all calls > into > > Rust and it's far cheaper to create a stack frame to catch a panic. > > > > This function is currently unstable, but it is up for stabilization [4] > in > > the 1.9 release (perhaps with a new name). It should be available > > immediately on nightly for experimenting, however. > > > > Let me know if that doesn't make sense or if you need any more info! > > > > [1]: https://github.com/rust-lang/rust/issues/30449 > > [2]: https://github.com/rust-lang/rust/pull/32282 > > [3]: http://doc.rust-lang.org/std/panic/fn.recover.html > > [4]: https://github.com/rust-lang/rust/issues/27719 > > > > On Tuesday, March 22, 2016 at 6:04:25 AM UTC-7, Henri Sivonen wrote: > > > It seems that the Rust MP4 parser is run a new Rust-created thread in > > > order to catch panics. Once we introduce Rust code that intermingles > > > with C++ more, it won't be practical to put all potentially panicing > > > Rust code into dedicated threads. > > > > > > Can we install a custom panic function that detects whether it's > > > running on a Rust-created thread and performs a normal Rust panic if > > > it is and performs a MOZ_CRASH if not (i.e. if it is on a > > > non-Rust-created thread)? > > > > > > -- > > > Henri Sivonen > > > hsivo...@hsivonen.fi > > > https://hsivonen.fi/ > > > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
