-
Notifications
You must be signed in to change notification settings - Fork 341
FAQ
A: Here is a longer version. In short, Napa.js provides a multi-threaded JavaScript programming model that enables developers to write computation heavy code in JavaScript, without blocking Node event loop.
You should use it when:
- CPU bound logic that may block Node event loop
- Complex workflow that may involve parallel execution of JavaScript code
A: Though JavaScript is already awesome without multi-threading today, we thought it could be even better if a wide spectrum of usage which are CPU bound can be supported, even thrive in JavaScript world. Napa.js is an experiment to this quest, simply because we have these requirements and cannot be satisfied with existing solutions.
There were lots of challenges, from API (how to expose multi-threading capability carefully without messing up single-thread simplicity of JavaScript) to performance (how to deal with message passing, and shared memory with minimum overhead). Through a 2-year journey, our usage in Bing confirmed this pattern actually worked. And we were glad to graduate Napa.js to the public. There is still a lot to do, our roadmap reveals some of these.
A relevant question is, how does Napa.js get along with Node.js? Since it's a runtime that builds from scratch, which can run without dependency on Node.js, also supporting modules in Node's way, does it make Napa.js a competitor of Node.js?
A short answer is No. We loved and benefited from Node.js so much, and appreciated its idea and ecosystem that makes building backend system much easier. With this consideration, instead of distributing Napa.js as a separate runtime, we distribute Napa.js as a node module. It's harder, we admit, since we have to take care of multiple Node versions, but it's healthier for the ecosystem. Also Napa.js is focusing on computational scenarios, so many core modules in Node like http are not supported by Napa. We take an approach to support core modules from Node only when it's absolutely necessary, either because they are also important to support computational scenarios, or they are widely used, that many cornerstone modules from NPM cannot run without. We will learn and see. Also, please bear in mind that how you use Napa.js might change the path.
To make Napa.js usable before supporting many Node modules, we introduced the concept of Node zone, through which you can offload IO work or any code depending on modules that Napa.js doesn't support to Node event loop.
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found
A: You didn't install the latest libstdc++6 libraries. This happens because the pre-built binaries are built by G++6. You have 2 choice -
-
Install the latest libstdc++6 libraries. Use the following command to install:
Firstly, install:
sudo apt-get install libstdc++6This should already be installed by default, but try it anyway. If it doesn't solve it, just do the following:
sudo add-apt-repository ppa:ubuntu-toolchain-r/test sudo apt-get update sudo apt-get upgrade sudo apt-get dist-upgrade(Solution from this post)
-
If you do not want to install/upgrade packages, you can also build napajs by yourself.
A: Yes and No. Napa.js support modules in the same way as Node.js does, but at present Napa.js doesn't support all Node.js built-in and core modules. If the module you want to use doesn't depend (directly or indirectly) on them, then you can use it, otherwise you cannot.
A: In JavaScript, each thread has its own heap, so you cannot access variable from different JavaScript thread. But, there are two ways you can communicate between JavaScript threads.
A: Currently Buffer is not supported by Napa.js (Transportable Types List). However, to transport the data in a Buffer object, we can use Uint8Array, which is transportable:
var byteArray = new Uint8Array(buf.buffer, buf.offset, buf.length);