| Age | Commit message (Collapse) | Author |
|---|
|
Moving some additional NAPI and. FFI tests out of the tree root.
|
|
This implements officially blessed and tested deno binaries for ARM64.
Thanks to @LukeChannings for his tireless work in maintaining the
deno-arm64 [1] repo, without which this project would have been far more
complicated. For those of you requiring support for older GLIBC
versions, that repo may still be required for the near future.
Limitations:
- This initial build is built on Ubuntu 22 using the stock GLIBC, which
will limit the utility of these binaries in certain use-cases (eg: early
versions of Ubuntu). We will attempt to support earlier versions of
ARM64 GLIBC in a later revision.
- Like the stock Linux x64 build, this is not a static build and
requires GLIBC. Running on Alpine will require installation of GLIBC.
Fixes #1846, #4862
[1] https://github.com/LukeChannings/deno-arm64
|
|
Most uses of `Deno.resources()` within tests, as they previously checked
for leaked resources. This is not needed as the test runner does this
automatically. Other internal uses of this API have been replaced with
the internal `Deno[Deno.internal].core.resources()`.
|
|
|
|
Re-attempt at #21284. I was more thorough this time.
---------
Signed-off-by: Asher Gomez <ashersaupingomez@gmail.com>
|
|
`Promise.withResolvers()` (#21234)
Closes #21041
---------
Signed-off-by: Asher Gomez <ashersaupingomez@gmail.com>
|
|
This reverts commit 20aa0796e6ff7651cdfce4d0292bdb11da5dfe2e.
`main` has been failing consistenly on `kv_undelivered_test` and
`serve_test` after this upgrade.
|
|
Closes #21002
|
|
Updated to deno_core 0.224.0 and V8 12.0.
---------
Co-authored-by: Aapo Alasuutari <aapo.alasuutari@gmail.com>
|
|
Fixes https://github.com/denoland/deno/issues/21005
|
|
This reverts commit 6e2abb2b13af5dff5d631fb1bc0c279c49ebd066.
|
|
|
|
Migrate to op2. Making a few decisions to get this across the line:
- Empty slices, no matter where the come from, are null pointers. The v8
bugs (https://bugs.chromium.org/p/v8/issues/detail?id=13489) and
(https://bugs.chromium.org/p/v8/issues/detail?id=13488) make passing
around zero-length slice pointers too dangerous as they might be
uninitialized or null data.
- Offsets and lengths are `#[number] isize` and `#[number] usize`
respectively -- 53 bits should be enough for anyone
- Pointers are bigints. This is a u64 in the fastcall world, and can
accept Integer/Int32/Number/BigInt v8 types in the slow world.
|
|
|
|
fix #17482
|
|
|
|
|
|
This patch makes `NativeType` to `libffi::middle::Type` conversion
failliable and w.t disallows struct with empty fields. libffi does not
handle "empty" struct because they don't exist in C (or Rust).
Fixes #17481
|
|
Adds support for passing and returning structs as buffers to FFI. This does not implement fastapi support for structs. Needed for certain system APIs such as AppKit on macOS.
|
|
Yearly tradition of creating extra noise in git.
|
|
Currently, slow call path will always create a dangling pointer to
replace a null pointer when called with eg. a `new Uint8Array()`
parameter, which V8 initialises as a null pointer backed buffer.
However, the fast call path will never change the pointer value and will
thus expose a null pointer. Thus, it's possible that the pointer value
that a native call sees coming from Deno changes between two sequential
invocations of the same function with the exact same parameters.
Since null pointers can be quite important, and `Uint8Array` is the
chosen fast path for Deno FFI `"buffer"` parameters, I think it is
fairly important that the null pointer be properly exposed to the native
code. Thus this PR.
### `*mut c_void`
While here, I also changed the type of our pointer values to `*mut
c_void`. This is mainly due to JS buffers always being `*mut`, and
because we offer a way to turn a pointer into a JS `ArrayBuffer`
(`op_ffi_get_buf`) which is read-write. I'm not exactly sure which way
we should really go here, we have pointers that are definitely mut but
we also cannot assume all of our pointers are. So, do we go with the
maxima or the minima?
### `optimisedCall(new Uint8Array())`
V8 seems to have a bug where calling an optimised function with a newly
created empty `Uint8Array` (no argument or 0) will not see the data
pointer being null but instead it's some stable pointer, perhaps
pointing to some internal null-backing-store. The pointer value is also
an odd (not even) number, so it might specifically be a tagged pointer.
This will probably be an issue for some users, if they try to use eg.
`method(cstr("something"), new Uint8Array())` as a way to do a fast call
to `method` with a null pointer as the second parameter.
If instead of a `new Uint8Array()` the user instead uses some `const
NULL = new Uint8Array()` where the `NULL` buffer has been passed to a
slow call previously, then the fast call will properly see a null
pointer.
I'll take this up with some V8 engineers to see if this couldn't be
fixed.
|
|
Fixes #15136
Currently `UnsafeCallback` class' `ref()` and `unref()` methods rely on
the `event_loop_middleware` implementation in core. If even a single
`UnsafeCallback` is ref'ed, then the FFI event loop middleware will
always return `true` to signify that there may still be more work for
the event loop to do.
The middleware handling in core does not wait a moment to check again,
but will instead synchronously directly re-poll the event loop and
middlewares for more work. This becomes a live-loop.
This PR introduces a `Future` implementation for the `CallbackInfo`
struct that acts as the intermediary data storage between an
`UnsafeCallback` and the `libffi` C callback. Ref'ing a callback now
means calling an async op that binds to the `CallbackInfo` Future and
only resolves once the callback is unref'ed. The `libffi` C callback
will call the waker of this Future when it fires to make sure that the
main thread wakes up to receive the callback.
|
|
|
|
|
|
|
|
Welcome to better optimised op calls! Currently opSync is called with parameters of every type and count. This most definitely makes the call megamorphic. Additionally, it seems that spread params leads to V8 not being able to optimise the calls quite as well (apparently Fast Calls cannot be used with spread params).
Monomorphising op calls should lead to some improved performance. Now that unwrapping of sync ops results is done on Rust side, this is pretty simple:
```
opSync("op_foo", param1, param2);
// -> turns to
ops.op_foo(param1, param2);
```
This means sync op calls are now just directly calling the native binding function. When V8 Fast API Calls are enabled, this will enable those to be called on the optimised path.
Monomorphising async ops likely requires using callbacks and is left as an exercise to the reader.
|
|
Co-authored-by: Phosra <phosra@tutanota.com>
|
|
|
|
|
|
|
|
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
This commit simplifies the TypeScript types used for interacting with Deno FFI. The basis is that types are now first grouped into logical wholes, NativeNumberType, NativeBigIntType etc. These wholes are combined into the NativeType and NativeResultType general types.
Additionally, this PR removes the { function: { parameters: [], result: "void" } } type declaration from parameters (and result types. Now functions are merely passed and returned as "function".
|
|
|
|
This commit adds support for unstable FFI
callbacks. A callback is registered using
the `Deno.UnsafeCallback` API.
The backing memory for the callback can
be disposed of using `Deno.UnsafeCallback#close`.
It is not safe to pass the callback after calling
close.
Callbacks from other than the isolate thread
are not supported.
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Co-authored-by: Bert Belder <bertbelder@gmail.com>
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Erfan Safari <erfanshield@outlook.com>
|
|
|
|
|
|
|
|
|
|
|
|
This commit adds support for passing buffer arguments across
FFI boundary.
Co-authored-by: eliassjogreen <eliassjogreen1@gmail.com>
Co-authored-by: Bert Belder <bertbelder@gmail.com>
|
