Re:Napa.js: A multi-threaded JavaScript runtime
by Touche on Wednesday October 18, 2017 @08:16AM
(#15498439)
This looks a lot like web workers, which Node.js does not have. Hopefully they will add it. https://github.com/nodejs/worker/issues/2
[ Parent
| on HN ]
Re:Napa.js: A multi-threaded JavaScript runtime
by je42 on Wednesday October 18, 2017 @08:30AM
(#15498561)
fork works fine in node.js
Re:Napa.js: A multi-threaded JavaScript runtime
by je42 on Wednesday October 18, 2017 @09:20AM
(#15498874)
why down vote ? fork is fine as long as the communication between the two processes is low-bandwidth.
Re:Napa.js: A multi-threaded JavaScript runtime
by Touche on Wednesday October 18, 2017 @09:52AM
(#15499123)
It works fine for many use cases but has serialization overhead.
Re:Napa.js: A multi-threaded JavaScript runtime
by nevir on Wednesday October 18, 2017 @11:11AM
(#15499747)
Shared memory & low overhead sharing of expensive objects is probably the primary reason to use Napa
Re:Napa.js: A multi-threaded JavaScript runtime
by MuffinFlavored on Wednesday October 18, 2017 @06:18PM
(#15503743)
I don't think Napa features shared memory though, does it?
Re:Napa.js: A multi-threaded JavaScript runtime
by daiyip on Thursday October 19, 2017 @02:53AM
(#15505957)
Since everything is in a single process, they can be shared via native structures. Each JS thread has its own heap, there will be a cost to transfer the shared native structures into JS object.
For complex objects, usually JSON is used thus marshall/unmarshall is needed. But for objects like UTF-8 string or ArrayBuffer, the same layout is used across JS and C++, thus at almost no cost.
Another thing is that between addon-modules, they can pass pointer of native structures (like Buffer) using 2 uint32 through JS. In this case, JS works as a binding language.