0
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-10-29 08:58:01 -04:00
denoland-deno/ops
Andreu Botella 68782346d0
feat(core): Reland support for async ops in realms (#17204)
Currently realms are supported on `deno_core`, but there was no support
for async ops anywhere other than the main realm. The main issue is that
the `js_recv_cb` callback, which resolves promises corresponding to
async ops, was only set for the main realm, so async ops in other realms
would never resolve. Furthermore, promise ID's are specific to each
realm, which meant that async ops from other realms would result in a
wrong promise from the main realm being resolved.

This change takes the `ContextState` struct added in #17050, and adds to
it a `js_recv_cb` callback for each realm. Combined with the fact that
that same PR also added a list of known realms to `JsRuntimeState`, and
that #17174 made `OpCtx` instances realm-specific and had them include
an index into that list of known realms, this makes it possible to know
the current realm in the `queue_async_op` and `queue_fast_async_op`
methods, and therefore to send the results of promises for each realm to
that realm, and prevent the ID's from getting mixed up.

Additionally, since promise ID's are no longer unique to the isolate,
having a single set of unrefed ops doesn't work. This change therefore
also moves `unrefed_ops` from `JsRuntimeState` to `ContextState`, and
adds the lengths of the unrefed op sets for all known realms to get the
total number of unrefed ops to compare in the event loop.

This PR is a reland of #14734 after it was reverted in #16366, except
that `ContextState` and `JsRuntimeState::known_realms` were previously
relanded in #17050. Another significant difference with the original PR
is passing around an index into `JsRuntimeState::known_realms` instead
of a `v8::Global<v8::Context>` to identify the realm, because async op
queuing in fast calls cannot call into V8, and therefore cannot have
access to V8 globals. This also simplified the implementation of
`resolve_async_ops`.

Co-authored-by: Luis Malheiro <luismalheiro@gmail.com>
2023-01-14 14:40:16 +01:00
..
optimizer_tests feat(core): Reland support for async ops in realms (#17204) 2023-01-14 14:40:16 +01:00
attrs.rs chore: update copyright year to 2023 (#17247) 2023-01-02 21:00:42 +00:00
Cargo.toml chore: forward 1.29.3 release back to main (#17401) 2023-01-13 13:36:51 -05:00
deno.rs chore: update copyright year to 2023 (#17247) 2023-01-02 21:00:42 +00:00
fast_call.rs feat(core): Reland support for async ops in realms (#17204) 2023-01-14 14:40:16 +01:00
lib.rs feat(core): Reland support for async ops in realms (#17204) 2023-01-14 14:40:16 +01:00
optimizer.rs chore: add copyright_checker tool and add the missing copyright (#17285) 2023-01-13 16:51:32 +09:00
README.md feat(ops): fast calls for Wasm (#16776) 2022-11-27 19:24:28 +05:30

deno_ops

proc_macro for generating highly optimized V8 functions from Deno ops.

// Declare an op.
#[op(fast)]
pub fn op_add(_: &mut OpState, a: i32, b: i32) -> i32 {
  a + b
}

// Register with an extension.
Extension::builder()
  .ops(vec![op_add::decl()])
  .build();

Performance

The macro can optimize away code, short circuit fast paths and generate a Fast API impl.

Cases where code is optimized away:

  • -> () skips serde_v8 and rv.set calls.
  • -> Result<(), E> skips serde_v8 and rv.set calls for Ok() branch.
  • -> ResourceId or -> [int] types will use specialized method like v8::ReturnValue::set_uint32. A fast path for SMI.
  • -> Result<ResourceId, E> or -> Result<[int], E> types will be optimized like above for the Ok() branch.

Fast calls

The macro will infer and try to auto generate V8 fast API call trait impl for sync ops with:

  • arguments: integers, bool, &mut OpState, &[u8], &mut [u8], &[u32], &mut [u32]
  • return_type: integers, bool

The #[op(fast)] attribute should be used to enforce fast call generation at compile time.

Trait gen for async ops & a ZeroCopyBuf equivalent type is planned and will be added soon.

Wasm calls

The #[op(wasm)] attribute should be used for calls expected to be called from Wasm. This enables the fast call generation and allows seamless WasmMemory integration for generic and fast calls.

#[op(wasm)]
pub fn op_args_get(
  offset: i32,
  buffer_offset: i32,
  memory: Option<&[u8]>, // Must be last parameter. Some(..) when entered from Wasm.
) {
  // ...
}