Marcel Laverdet
Marcel Laverdet
I agree that this is surprising. I came up with this example which is a little easier to reason about: ```js const ivm = require('isolated-vm'); const isolate = new ivm.Isolate;...
Wouldn't importScripts look something like this? ```js await context.evalClosure( `importScripts = (...args) => $0.applySyncPromise(undefined, args).map(eval)`, [ async (...files) => { const contents = await Promise.all(files.map(file => fs.promises.readFile(file, 'utf8'))); return new...
I think you need to use `ExternalCopy` manually here because the return value is an array (non-transferable) and `applyPromiseSync` doesn't support `{ copy: true }` because of annoying technical issues.
We can diff it from npm, looks like some logging changes.. maybe some internal meteor diagnostics that snuck into npm? @renanccastro would be able to comment further. ``` diff -pubr...
cc: @benjamn
Well there's two problems I see with that. The first is that it will add some overhead to all nodejs applications just for the sake of node-fibers. I don't think...
> I understand your skepticism, but I think this idea is important to make async_hooks thread-aware in a general sense, so it wouldn't be just for the sake of fibers....
I don't think v8 exposes the thread id anywhere so you would have to use a private API (like node-fibers does, very naughty) to get it. You could leak memory...
upgrade fibers
There's a note on the front page README about this. Fibers will not be supported on nodejs v16.x or higher.