mirror of
https://github.com/denoland/deno.git
synced 2025-01-10 16:11:13 -05:00
7807afa972
Additionally, instead of polling ops in a loop until none of them are ready, the isolate will now yield to the task system after delivering the first batch of completed ops to the javascript side. Although this makes performance a bit worse (about 15% fewer requests/second on the 'deno_core_http_bench' benchmark), we feel that the advantages are worth it: * It resolves the extremely high worst-case latency that we were seeing on deno_core_http_bench, in particular when using the multi-threaded Tokio runtime, which would sometimes exceed a full second. * Before this patch, the implementation of Isolate::poll() had to loop through all sub-futures and poll each one of them, which doesn't scale well as the number of futures managed by the isolate goes up. This could lead to poor performance when e.g. a server is servicing thousands of connected clients. |
||
|---|---|---|
| .. | ||
| libdeno | ||
| BUILD.gn | ||
| build.rs | ||
| Cargo.toml | ||
| core.d.ts | ||
| flags.rs | ||
| http_bench.js | ||
| http_bench.rs | ||
| isolate.rs | ||
| js_errors.rs | ||
| lib.rs | ||
| libdeno.rs | ||
| modules.rs | ||
| README.md | ||
| shared_queue.js | ||
| shared_queue.rs | ||
| shared_queue_test.js | ||
Deno Core
This Rust crate contains the essential V8 bindings for Deno's command-line
interface (Deno CLI). The main abstraction here is the Isolate which proivdes a
way to execute JavaScript. The Isolate is modeled as a
Future<Item=(), Error=JSError> which completes once all of its ops have
completed. The user must define what an Op is by implementing the Dispatch
trait, and by doing so define any "built-in" functionality that would be
provided by the VM. Ops are triggered by Deno.core.dispatch().
Documentation for this crate is thin at the moment. Please see http_bench.rs as a simple example of usage.
TypeScript support and a lot of other functionality is not available at this layer. See the cli for that.