You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you want to use any syscalls, you need native addons. As a consequence, you need builds for every architecture. Also bundling a single JS file / minification / packing a single executable gets quite hard once addons are involved.
What is the feature you are proposing to solve the problem?
Providing a syscall API in Node itself would completely remove the need for architecture specific builds and one could generate "run-everywhere" JS files.
The hard part in solving this is probably the buffer / pointer handling. Syscalls require pointers and sometimes also data structures with pointers. Pointers are 64-bit wide on most modern platforms, hence APIs would use BigInt. In order to provide a syscall API, one would also need APIs to retrieve memory addresses of ArrayBuffers.
But then asynchronicity enters the game (because we want an async syscall API, right?), which means the garbage collector may not collect buffers that are referenced in the currently running syscalls. That also includes indirectly referenced buffers (e.g. a pointer in a data structure given to the kernel). While this could probably be done in JS itself, it still poses a high risk, as it could cause all sorts of strange behaviours if the kernel writes into memory that is reused during the syscall due to garbage collection.
The "nice" approach would probably be to explicitly lock and unlock the buffers, obtaining a memory address in the process.
On the other hand, there are cases where the kernel provides buffers to the userspace (e.g. mmap). In order to utilize this, we would need an API to instantiate a buffer based on the memory address and size.
Syscall numbers and ABI are architecture dependent, but could probably easily be handeled in JS if we know the architecture and platform (which we should?).
So in my eyes we would need something like:
os.syscall() - takes an array of BigInts, returns Promise of BigInt
os.syscallSync() - takes an array of BigInts, returns BigInt
What is the problem this feature will solve?
If you want to use any syscalls, you need native addons. As a consequence, you need builds for every architecture. Also bundling a single JS file / minification / packing a single executable gets quite hard once addons are involved.
Also, see #39436
What is the feature you are proposing to solve the problem?
Providing a syscall API in Node itself would completely remove the need for architecture specific builds and one could generate "run-everywhere" JS files.
The hard part in solving this is probably the buffer / pointer handling. Syscalls require pointers and sometimes also data structures with pointers. Pointers are 64-bit wide on most modern platforms, hence APIs would use BigInt. In order to provide a syscall API, one would also need APIs to retrieve memory addresses of ArrayBuffers.
But then asynchronicity enters the game (because we want an async syscall API, right?), which means the garbage collector may not collect buffers that are referenced in the currently running syscalls. That also includes indirectly referenced buffers (e.g. a pointer in a data structure given to the kernel). While this could probably be done in JS itself, it still poses a high risk, as it could cause all sorts of strange behaviours if the kernel writes into memory that is reused during the syscall due to garbage collection.
The "nice" approach would probably be to explicitly lock and unlock the buffers, obtaining a memory address in the process.
On the other hand, there are cases where the kernel provides buffers to the userspace (e.g. mmap). In order to utilize this, we would need an API to instantiate a buffer based on the memory address and size.
Syscall numbers and ABI are architecture dependent, but could probably easily be handeled in JS if we know the architecture and platform (which we should?).
So in my eyes we would need something like:
This is of course mainly with Linux in mind, not sure about Windows.
What alternatives have you considered?
If node addons could be loaded via "data:" URLs, you could probably also get very far in creating "run-everywhere" JS files.
The text was updated successfully, but these errors were encountered: