1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-12-04 17:18:23 -05:00
Commit graph

19 commits

Author SHA1 Message Date
Leo Kettmeir
eca83fc9b4
refactor(ext/web): use concrete error types (#26185) 2024-10-17 19:05:38 +00:00
Nathan Whitaker
dd8cbf5e29
fix(node): fix worker_threads issues blocking Angular support (#26024)
Fixes #22995. Fixes #23000.

There were a handful of bugs here causing the hang (each with a
corresponding minimized test):

- We were canceling recv futures when `receiveMessageOnPort` was called,
but this caused the "receive loop" in the message port to exit. This was
due to the fact that `CancelHandle`s are never reset (i.e., once you
`cancel` a `CancelHandle`, it remains cancelled). That meant that after
`receieveMessageOnPort` was called, the subsequent calls to
`op_message_port_recv_message` would throw `Interrupted` exceptions, and
we would exit the loop.

The cancellation, however, isn't actually necessary.
`op_message_port_recv_message` only borrows the underlying port for long
enough to poll the receiver, so the borrow there could never overlap
with `op_message_port_recv_message_sync`.

- Calling `MessagePort.unref()` caused the "receive loop" in the message
port to exit. This was because we were setting
`messageEventListenerCount` to 0 on unref. Not only does that break the
counter when multiple `MessagePort`s are present in the same thread, but
we also exited the "receive loop" whenever the listener count was 0. I
assume this was to prevent the recv promise from keeping the event loop
open.

Instead of this, I chose to just unref the recv promise as needed to
control the event loop.

- The last bug causing the hang (which was a doozy to debug) ended up
being an unfortunate interaction between how we implement our
messageport "receive loop" and a pattern found in `npm:piscina` (which
angular uses). The gist of it is that piscina uses an atomic wait loop
along with `receiveMessageOnPort` in its worker threads, and as the
worker is getting started, the following incredibly convoluted series of
events occurs:
   1. Parent sends a MessagePort `p` to worker
   2. Parent sends a message `m` to the port `p`
3. Parent notifies the worker with `Atomics.notify` that a new message
is available
   4. Worker receives message, adds "message" listener to port `p`
   5. Adding the listener triggers `MessagePort.start()` on `p`
6. Receive loop in MessagePort.start receives the message `m`, but then
hits an await point and yields (before dispatching the "message" event)
7. Worker continues execution, starts the atomic wait loop, and
immediately receives the existing notification from the parent that a
message is available
8. Worker attempts to receive the new message `m` with
`receiveMessageOnPort`, but this returns `undefined` because the receive
loop already took the message in 6
9. Atomic wait loop continues to next iteration, waiting for the next
message with `Atomic.wait`
10. `Atomic.wait` blocks the worker thread, which prevents the receive
loop from continuing and dispatching the "message" event for the
received message
11. The parent waits for the worker to respond to the first message, and
waits
12. The thread can't make any more progress, and the whole process hangs

The fix I've chosen here (which I don't particularly love, but it works)
is to just delay the `MessagePort.start` call until the end of the event
loop turn, so that the atomic wait loop receives the message first. This
prevents the hang.

---

Those were the main issues causing the hang. There ended up being a few
other small bugs as well, namely `exit` being emitted multiple times,
and not patching up the message port when it's received by
`receiveMessageOnPort`.
2024-10-04 09:26:32 -07:00
Bartek Iwańczuk
760d64bc6b
fix(ext/node): worker_threads.receiveMessageOnPort doesn't panic (#23406)
Follow up to https://github.com/denoland/deno/pull/23386.
Instead of using async `recv()` method, it was replaced
with a poll based function that doesn't hold onto
RefCell borrow across await point.

Fixes https://github.com/denoland/deno/issues/23362
2024-04-16 18:41:03 +00:00
Bartek Iwańczuk
0b8d7d1d4b
fix(ext/node): panic on 'worker_threads.receiveMessageOnPort' (#23386)
Closes https://github.com/denoland/deno/issues/23362

Previously we were panicking if there was a pending read on a
port and `receiveMessageOnPort` was called. This is now fixed
by cancelling the pending read, trying to read a message and
resuming reading in a loop.
2024-04-16 01:06:39 +02:00
Bartek Iwańczuk
92576fdcfd
fix(ext/node): support MessagePort in WorkerOptions.workerData (#22950)
This commit fixes passing `MessagePort` instances to
`WorkerOptions.workerData`.

Before they were not serialized and deserialized properly when spawning
a worker thread.

Closes https://github.com/denoland/deno/issues/22935
2024-03-16 01:59:18 +01:00
mash-graz
80dbcd3ddf
fix(ext/node) implement receiveMessageOnPort for node:worker_threads (#22766)
Implementation of `receiveMessageOnPort` for `node:worker_threads`

Fixes: #22702
2024-03-11 00:23:06 +01:00
David Sherret
7e72f3af61
chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
Bartek Iwańczuk
5e7435fb80
refactor: rewrite more ops to op2 macro (#20478) 2023-09-14 23:05:18 +02:00
Matt Mastracci
bfd230fd78
chore: update inner #\![allow] to #[allow] (#20463)
Functions should generally be annotated with `#[allow]` blocks rather
than using inner `#![allow]` annotations.
2023-09-11 17:12:33 -06:00
Divy Srivastava
d5634164cb
chore: use rustfmt imports_granularity option (#17421)
Closes https://github.com/denoland/deno/issues/2699
Closes https://github.com/denoland/deno/issues/2347

Uses unstable rustfmt features. Since dprint invokes `rustfmt` we do not
need to switch the cargo toolchain to nightly. Do we care about
formatting stability of our codebase across Rust versions? (I don't)
2023-01-14 23:18:58 -05:00
Yiyu Lin
a00e432297
chore: add copyright_checker tool and add the missing copyright (#17285) 2023-01-13 16:51:32 +09:00
Andreu Botella
018ad9b3a4
chore(web, worker): Use DetachedBuffer for postMessage ops (#15133)
This commit uses `DetachedBuffer` instead of `ZeroCopyBuf` in the ops
that back `Worker.prototype.postMessage` and
`MessagePort.prototype.postMessage`. This is done because the
serialized buffer is then copied to the destination isolate, even
though it is internal to runtime code and not used for anything else,
so detaching it and transferring it instead saves an unnecessary copy.
2022-07-11 17:27:33 +02:00
Andreu Botella
3e7afb8918
chore(runtime): Make some ops in ext and runtime infallible. (#14589)
Co-authored-by: Aaron O'Mullan <aaron.omullan@gmail.com>
2022-05-13 10:36:31 +02:00
Aaron O'Mullan
88d0f01948
feat(ops): custom arity (#13949)
Also cleanup & drop ignored wildcard op-args
2022-03-14 23:38:53 +01:00
Divy Srivastava
b4e42953e1
feat(core): codegen ops (#13861)
Co-authored-by: Aaron O'Mullan <aaron.omullan@gmail.com>
2022-03-14 18:44:15 +01:00
Ryan Dahl
7c2abb9d57
fix: Deno.emit crashes with BorrowMutError (#12627)
Warn on await_holding_refcell_ref clippy rule to avoid this in the future.

Fixes #12453
2021-11-03 09:27:36 -04:00
Luca Casonato
5d814a4c24
feat: ArrayBuffer in structured clone transfer (#11840) 2021-08-25 13:48:53 +02:00
Aaron O'Mullan
2ca454b402
refactor(ops): return BadResource errors in ResourceTable calls (#11710)
* refactor(ops): return BadResource errors in ResourceTable calls

Instead of relying on callers to map Options to Results via `.ok_or_else(bad_resource_id)` at over 176 different call sites ...
2021-08-15 13:29:19 +02:00
Ryan Dahl
a0285e2eb8
Rename extensions/ directory to ext/ (#11643) 2021-08-11 12:27:05 +02:00
Renamed from extensions/web/message_port.rs (Browse further)