nodeWorker cannot syscall.callNow #1617
Assignees
Labels
Comments
|
I will add a test case for this |
warner
added a commit
that referenced
this issue
Jan 19, 2021
This is the only type of worker which can currently handle syscall.callNow. The `node-subprocess` case theoretically could (the child subprocess could do a blocking read of the kernel-to-worker pipe while waiting for the result), but the code on either side of that pipe does not yet support that mode. The `nodeWorker` (Node.js threads) case cannot, because threads cannot block, at least not without heroics involving `Atomic` locks around a results-bearing `SharedArrayBuffer`. The old `xs-worker` case could not, for the same shallow implementation reasons as `node-subprocess`, but the new `xsnap` -based XS worker should be capable. closes #1617
dckc
pushed a commit
that referenced
this issue
Jan 21, 2021
This is the only type of worker which can currently handle syscall.callNow. The `node-subprocess` case theoretically could (the child subprocess could do a blocking read of the kernel-to-worker pipe while waiting for the result), but the code on either side of that pipe does not yet support that mode. The `nodeWorker` (Node.js threads) case cannot, because threads cannot block, at least not without heroics involving `Atomic` locks around a results-bearing `SharedArrayBuffer`. The old `xs-worker` case could not, for the same shallow implementation reasons as `node-subprocess`, but the new `xsnap` -based XS worker should be capable. closes #1617
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
context: #1407 (comment)
cc @warner
The text was updated successfully, but these errors were encountered: