Peg isolates to a thread, replace all usage of tokio threaded runtime with tokio's basic runtime

[ry]

No description provided.

[bartlomieju]

LGTM, this patch is massive and requires a few more follow ups

[piscisaureus]

So the Isolate is still a future if I'm reading this correctly.
Is there a way to make the V8 thread drive the tokio event loop instead of the other way around? Otherwise I don't see it going to help much with the Locker issue.

[piscisaureus]

2. Does this mean that all blocking ops (e.g. DNS resolution) are now actually blocking, or is there still a thread pool for that?

[ry]

So the Isolate is still a future if I'm reading this correctly. Is there a way to make the V8 thread drive the tokio event loop instead of the other way around? Otherwise I don't see it going to help much with the Locker issue.

Probably. The event loop is basically defined the same as it was in deno_core::Isolate::poll. Now that they are all on their own threads we can start to dismantle that if we want to. I avoided making more changes than necessary to switch Tokio runtimes.

Does this mean that all blocking ops (e.g. DNS resolution) are now actually blocking, or is there still a thread pool for that?

In this patch all blocking ops are done on their own thread. I leave it to future work to optimize this.
https://github.com/ry/deno/blob/b5ca5e6f0aa2cbb732827f745bb5e7cf15641a17/cli/ops/dispatch_json.rs#L106-L113

[piscisaureus]

In this patch all blocking ops are done on their own thread. I leave it to future work to optimize this.
https://github.com/ry/deno/blob/b5ca5e6f0aa2cbb732827f745bb5e7cf15641a17/cli/ops/dispatch_json.rs#L106-L113

Although the code looks fine from my perspective, I worry that it's going to hurt some benchmark performance badly. Do you have any numbers for e.g. module fetch / proxy performance?

[ry]

Note that we've gotten rid of this Arc Mutex

[ry]

Although the code looks fine from my perspective, I worry that it's going to hurt some benchmark performance badly. Do you have any numbers for e.g. module fetch / proxy performance?

I don't think we measure any blocking ops in the benchmarks. Regarding compiling - we spawn a new thread for the TS compiler worker - so that's an async op.

[piscisaureus]

In this patch all blocking ops are done on their own thread. I leave it to future work to optimize this.

I'm a bit afraid this is is never going to happen.

[hustxiaoc]

Are we going to use threaded_scheduler runtime someday for handling async ops with multiple threading?

[ry]

@hustxiaoc Unlikely - we have in the past and have found the single threaded runtime faster and simpler for our purposes. I'd be happy to describe this in more detail if you're interested...

[hustxiaoc]

Sure, I'm happy to learn more detail about this :)