News for hackers. Stuff that matters.
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.