segmentation fault when running multiple runtimes

[denoland]

segmentation fault when running multiple runtimes

[mmastrac]

I'm not aware of any v8 limitations on multiple isolates in one thread, but I would strongly recommend against it as we may end up internalizing the the tokio runtime inside of the JsRuntime for performance reasons at some time in the future.

JsRealm is intended to separate scripts from each other (they use a v8::Context internally), but realms are still in development and may have some sharp edges w.r.t. performance and security. For now, the best supported way to run parallel isolates is one-per-thread.

[jsen-]

Thank you for the JsRealm tip. I don't see the performance nor security as an issue (all scripts will be written internally and will mostly be waiting for API responses). There will be 0 - 300 of them running in parallel, though.
I tried it and it works, but the implementation is kinda crazy 🙂 and I'm still missing the ability to "pause" and "cancel" individual JsRealms.

Feel free to close this issue (unless you'd like to keep it open with regards to the segfault). Thanks again

[abadcafe]

@jsen- I think your problem maybe related to this issue: denoland/rusty_v8#639 .

The root cause is, v8::Isolate::new() included a call of v8::Isolate->Enter() and the drop() method of Isolate included a call of v8::Isolate->Exit(), which required isolates in a thread must destruct in last-in-first-out order.

If this is your case, then the simplest way to fix it is just use FuturesOrdered and its push_front() method to ensure JsRuntimes destruct in reversed order of create. But I recommend you just remove the Enter() and Exit() pair in rusty_v8 source code, as it has no sense in single thread embedding situation.

And as a deno_core user, I really don't like the idea to encapsulate tokio and thread-related things into deno_core. This way will limit the usage of deno_core in a very narrow scope. I beg you core developers to re-consider this idea @mmastrac .