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
