| Age | Commit message (Collapse) | Author |
|---|
|
This is the release commit being forwarded back to main for 2.0.4
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
|
|
Forwarding v2.0.3 commit to `main`
Co-authored-by: denobot <33910674+denobot@users.noreply.github.com>
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
|
|
This is the release commit being forwarded back to main for 2.0.2
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
This is the release commit being forwarded back to main for 2.0.1
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
Bumped versions for 2.0.0
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
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`.
|
|
Testing once again if the crates are being properly released.
---------
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
Test run before Deno 2.0 release to make sure that the publishing
process passes correctly.
---------
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
|
|
This PR optimizes the case when `performance.measure()` needs to find
the startMark by name. It is a simple change on `findMostRecent` fn to
avoiding copying and reversing the complete entries list.
Adds minor missing tests for:
- `clearMarks()`, general
- `clearMeasures()`, general
- `measure()`, case when the startMarks name exists more than once
### Benchmarks
#### main
```
CPU | AMD Ryzen 7 PRO 6850U with Radeon Graphics
Runtime | Deno 2.0.0-rc.4 (x86_64-unknown-linux-gnu)
benchmark time/iter (avg) iter/s (min … max) p75 p99 p995
---------------------- ----------------------------- --------------------- --------------------------
worst case measure() 2.1 ms 486.9 ( 1.7 ms … 2.4 ms) 2.2 ms 2.4 ms 2.4 ms
```
#### this PR
```
CPU | AMD Ryzen 7 PRO 6850U with Radeon Graphics
Runtime | Deno 2.0.0-rc.4 (x86_64-unknown-linux-gnu)
benchmark time/iter (avg) iter/s (min … max) p75 p99 p995
---------------------- ----------------------------- --------------------- --------------------------
worst case measure() 966.3 µs 1,035 (876.9 µs … 1.1 ms) 1.0 ms 1.1 ms 1.1 ms
```
```ts
Deno.bench("worst case measure()", (b) => {
performance.mark('start');
for (let i = 0; i < 1e5; i += 1) {
performance.mark(crypto.randomUUID());
}
b.start();
performance.measure('total', 'start');
b.end();
performance.clearMarks();
performance.clearMeasures();
});
```
|
|
This fixes the fast path for `readableStreamCollectIntoUint8Array` to
only trigger if the readable stream has not yet been disturbed -
because otherwise we may not be able to close it if the
read errors.
|
|
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>
|
|
This is the release commit being forwarded back to main for 1.46.3
|
|
Co-authored-by: crowlkats <crowlkats@toaxl.com>
|
|
Remove `--allow-hrtime` and `--deny-hrtime`. We are doing this because
it is already possible to get access to high resolution timers through
workers and SharedArrayBuffer.
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
This is the release commit being forwarded back to main for 1.46.2
|
|
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
|
|
Unfortunately this caused a regression:
https://github.com/denoland/deno/issues/25203.
Need to do some more upstream spec work to fix this before this can be
re-landed.
Reverts denoland/deno#24623
|
|
|
|
Bumped versions for 1.46.0
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
|
|
Fixes https://github.com/denoland/deno/issues/24878
|
|
Implements https://github.com/whatwg/webidl/pull/1397
Fixes #21454
Closes #24849
|
|
|
|
Reverts denoland/deno#24402
deno_web can't depend on code in runtime
|
|
We are switching to ContinuationPreservedEmbedderData. This allows
adding async context tracking to the various async operations that deno
provides.
Fixes: https://github.com/denoland/deno/issues/7010
Fixes: https://github.com/denoland/deno/issues/22886
Fixes: https://github.com/denoland/deno/issues/24368
|
|
|
|
|
|
Fixes https://github.com/denoland/deno/issues/24323
- Use a Buffer pool for `fromString`
- Implement fast call base64 writes
- Direct from string `create` method for each encoding op
```
$ deno bench -A bench.mjs # 1.45.1+fee4d3a
cpu: Apple M1 Pro
runtime: deno 1.45.1+fee4d3a (aarch64-apple-darwin)
benchmark time (avg) (min … max) p75 p99 p999
----------------------------------------------------------- -----------------------------
Buffer.from base64 550 ns/iter (490 ns … 1'265 ns) 572 ns 606 ns 1'265 ns
Buffer#write base64 285 ns/iter (259 ns … 371 ns) 307 ns 347 ns 360 ns
$ ~/gh/deno/target/release/deno bench -A bench.mjs # this PR
cpu: Apple M1 Pro
runtime: deno dev (aarch64-apple-darwin)
benchmark time (avg) (min … max) p75 p99 p999
----------------------------------------------------------- -----------------------------
Buffer.from base64 151 ns/iter (145 ns … 770 ns) 148 ns 184 ns 648 ns
Buffer#write base64 62.58 ns/iter (60.79 ns … 157 ns) 61.65 ns 75.79 ns 141 ns
$ node bench.mjs # v22.4.0
cpu: Apple M1 Pro
runtime: node v22.4.0 (arm64-darwin)
benchmark time (avg) (min … max) p75 p99 p999
----------------------------------------------------------- -----------------------------
Buffer.from base64 163 ns/iter (96.92 ns … 375 ns) 99.45 ns 127 ns 220 ns
Buffer#write base64 75.48 ns/iter (74.97 ns … 134 ns) 75.17 ns 81.83 ns 96.84 ns
```
|
|
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
This is the release commit being forwarded back to main for 1.45.3
---------
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
(#24599)
Fix #24578
Fix #21981
|
|
Co-authored-by: dsherret <dsherret@users.noreply.github.com>
|
|
This is the release commit being forwarded back to main for 1.45.1
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
|
|
Bumped versions for 1.45.0
---------
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
accessing e.g. `Buffer` in `Mode::Deno` mode should throw, not return
undefined.
---------
Signed-off-by: snek <snek@deno.com>
|
|
Ref: https://github.com/denoland/deno_core/issues/135
|
|
|
|
This is the release commit being forwarded back to main for 1.44.4
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
|
|
This is the release commit being forwarded back to main for 1.44.3
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
<!--
Before submitting a PR, please read
https://docs.deno.com/runtime/manual/references/contributing
1. Give the PR a descriptive title.
Examples of good title:
- fix(std/http): Fix race condition in server
- docs(console): Update docstrings
- feat(doc): Handle nested reexports
Examples of bad title:
- fix #7123
- update docs
- fix bugs
2. Ensure there is a related issue and it is referenced in the PR text.
3. Ensure there are tests that cover the changes.
4. Ensure `cargo test` passes.
5. Ensure `./tools/format.js` passes without changing files.
6. Ensure `./tools/lint.js` passes.
7. Open as a draft PR if your work is still in progress. The CI won't
run
all steps, but you can add '[ci]' to a commit message to force it to.
8. If you would like to run the benchmarks on the CI, add the 'ci-bench'
label.
-->
Fixes #20663.
---------
Co-authored-by: Asher Gomez <ashersaupingomez@gmail.com>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
|
|
I was able to use my experience with some of the Deno extensions to
flesh out their documentation a bit
I've provided docs for the following:
- web
- fetch
- net
- webidl
- url
- io
- crypto
- console
---------
Signed-off-by: Richard Carson <Rscarson@rogers.com>
|
|
|
|
Co-authored-by: nathanwhit <nathanwhit@users.noreply.github.com>
|
