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
