| Age | Commit message (Collapse) | Author |
|---|
|
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`.
|
|
Closes https://github.com/denoland/deno/issues/25911
|
|
`temporalio` sdk [will try to
use](https://github.com/temporalio/sdk-typescript/blob/faa64225a7f57154931a38c1fe612fc6520943b2/packages/worker/src/workflow/vm-shared.ts#L199-L202)
promiseHook if it is found. This patch removes the unimplemented stubs.
```ts
if (promiseHooks) {
// Node >=16.14 only
this.stopPromiseHook = promiseHooks.createHook({
init: (promise: Promise<unknown>, parent: Promise<unknown>) => {
```
Fixes https://github.com/denoland/deno/issues/25977
|
|
env var (#25896)
Fixes https://github.com/denoland/deno/issues/25401. Fixes
https://github.com/denoland/deno/issues/25841. Fixes
https://github.com/denoland/deno/issues/25891.
|
|
Fixes https://github.com/denoland/deno/issues/25844
|
|
From
https://github.com/denoland/deno/commit/18b89d948dcb849c4dc577478794c3d5fb23b59
May have caused the recent flakiness of
parallel/test-child-process-ipc-next-tick.js
|
|
Fixes cjs modules being loaded as esm.
|
|
(#25699)
|
|
Closes https://github.com/denoland/deno/issues/25604
Signed-off-by: Satya Rohith <me@satyarohith.com>
Co-authored-by: Satya Rohith <me@satyarohith.com>
|
|
Reverts #25690
This was not an issue with the ts compiler anymore. Discussion here:
https://github.com/dprint/dprint-plugin-typescript/pull/664#issuecomment-2357000053
|
|
Signed-off-by: Divy Srivastava <dj.srivastava23@gmail.com>
|
|
Closes #22583
|
|
|
|
|
|
|
|
`kBindStreamsLazy` should be called with `process` during init, but it
never was.
|
|
Toward #24236
|
|
|
|
Fixes https://github.com/denoland/deno/issues/25193.
|
|
This change fixes Decipheriv behavior when autoPadding disabled and enabled.
By this change, the example given in
https://github.com/denoland/deno/issues/20924#issuecomment-2345931295
works in the same way as Node.
closes #20924
|
|
Closes https://github.com/denoland/deno/issues/20612
Closes https://github.com/denoland/deno/issues/23326
This makes `qwik` work.
|
|
Exposes following modules:
- `"node:_http_agent"`
- `"node:_http_common"`
- `"node:_http_outgoing"`
- `"node:_http_server"`
- `"node:_stream_duplex"`
- `"node:_stream_passthrough"`
- `"node:_stream_readable"`
- `"node:_stream_transform"`
- `"node:_stream_writable"`
- `"node:_tls_common"`
- `"node:_tls_wrap"`
|
|
|
|
That puts us at 99.5% compatibility for this module.
|
|
|
|
|
|
|
|
This PR adds `writeFile` methods of `FileHandle` class
https://nodejs.org/api/fs.html#filehandlewritefiledata-options
|
|
Contributing toward #24236
- Swapped `Object.assign` for `ObjectAssign` primordial.
- Removed referencing TODO comment.
Please disregard if no longer desired.
|
|
Just a bunch of random fs constants
|
|
Apparently `path/posix` and `path/win32` have circular exports. I do not
know why.
Additionally there's a deprecated function `_makeLong` which is just
`toNamespacedPath`
|
|
Closes #20613.
Reimplements the serialization on top of the v8 APIs instead of
deno_core. Implements `v8.Serializer`, `v8.DefaultSerializer`,
`v8.Deserializer`, and `v8.DefaultSerializer`.
|
|
implement require(esm) using `op_import_sync` from deno_core.
possible future changes:
- cts and mts
- replace Deno.core.evalContext to optimize esm syntax detection
Fixes: https://github.com/denoland/deno/issues/25487
|
|
Closes #7394
---------
Co-authored-by: snek <snek@deno.com>
|
|
Closes https://github.com/denoland/deno/issues/25526
|
|
A workaround for the issue #25480
`Deno.Listener` can't be closed synchronously after `accept()` is
called. This PR delays the `accept` call 2 ticks (The listener callback
is called 1 tick later. So the 1 tick delay is not enough), and makes
`net.Server` capable of being closed synchronously.
This unblocks `npm:detect-port` and `npm:portfinder`
closes #18301
closes #25175
|
|
proceed with #23921
This PR is a preparation for
https://github.com/denoland/deno_lint/pull/1307
---------
Signed-off-by: Kenta Moriuchi <moriken@kimamass.com>
Co-authored-by: Luca Casonato <hello@lcas.dev>
|
|
closes #23401
|
|
Towards #22079
|
|
This commit adds:
- `addAbortListener` in `node:events`
- `aborted` in `node:util`
- `execPath` and `execvArgs` named export from `node:process`
- `getDefaultHighWaterMark` from `node:stream`
The `execPath` is very hacky - because module namespaces can not have
real getters, `execPath` is an object with a `toString()` method that on
call returns the actual `execPath`, and replaces the `execPath` binding
with the string. This is done so that we don't require the `execPath`
permission on startup.
|
|
|
|
`deno bundle` now produces:
```
error: ⚠️ `deno bundle` was removed in Deno 2.
See the Deno 1.x to 2.x Migration Guide for migration instructions: https://docs.deno.com/runtime/manual/advanced/migrate_deprecations
```
`deno bundle --help` now produces:
```
⚠️ `deno bundle` was removed in Deno 2.
See the Deno 1.x to 2.x Migration Guide for migration instructions: https://docs.deno.com/runtime/manual/advanced/migrate_deprecations
Usage: deno bundle [OPTIONS]
Options:
-q, --quiet Suppress diagnostic output
--unstable Enable all unstable features and APIs. Instead of using this flag, consider enabling individual unstable features
To view the list of individual unstable feature flags, run this command again with --help=unstable
```
|
|
Closes https://github.com/denoland/deno/issues/15207
|
|
Signed-off-by: Caleb Lloyd <caleblloyd@gmail.com>
|
|
|
|
This reverts commit 71ca61e189cca9215982ce4598b7a4da8430c584.
Now uses a shared implementation from deno_core.
|
|
To ensure consistency across the codebase, this commit refactors the
code in the `ext` folder to use `throw new Error`` instead of `throw`
for throwing errors.
Fixes https://github.com/denoland/deno/issues/25270
|
|
Turns out we only virtualized it so one could have a `Console` property,
and the other one not. We can just make this `console.Console` available
everywhere.
|
|
Fixes https://github.com/denoland/deno/issues/24129
|
|
Fixes https://github.com/denoland/deno/issues/18928
Signed-off-by: Divy Srivastava <dj.srivastava23@gmail.com>
|
