> I would like to understand the implications. Does this improve performance? Or does it just allow coding in C++.
This is practically a C++ wrapper for libuv, the backend of node.js. It allows you to write code similar to node.js in C++ without using JavaScript and the V8 JavaScript environment. Does it improve performance? In theory, yes. In practice, maybe.
The biggest potential win here is that you could run many threads that can run I/O in parallel. In Node.js/V8 you only have one native OS thread while in C++ you can put many native threads to serve the I/O sockets. It's quite a lot cheaper to change from one thread to another than it is to change from one process to another (if you have many node.js processes running) so there is potential for performance increases if you have some CPU-heavy stuff in your code. Or you have more sockets/requests to serve than a single CPU is capable of.
This is assuming that libuv and node.native don't have anything that would inhibit running in multiple threads. The system calls running underneath (read, write, epoll/kqueue) are thread safe, but libuv/node.native may have something that isn't. I didn't double-check.
> To clarify, node already has parallelized I/O threads. The only thing that isn't parallelized is the JS-land code.
But Node.js runs only in a single native thread, right? So it's single threaded I/O multiplexing using epoll/kqueue and the thread calls JS callbacks when some I/O takes place. In C or C++ you could run n native threads serving m sockets using a single "reactor".
Node.js only has a single thread for the event loop. (where the user's javascript is run) Internally it uses a thread pool.
You could certainly do what you describe and it would be very similar to node's Cluster module, which uses multiple processes. In fact, I believe in the next release they're giving you the option to replace processes with threads under the hood.
That actually isn't the case anymore. It has been removed for various reasons, a major one is stability. While the promise of isolates was nice, I think the choice to remove them was a good one considering the tradeoffs.
This is practically a C++ wrapper for libuv, the backend of node.js. It allows you to write code similar to node.js in C++ without using JavaScript and the V8 JavaScript environment. Does it improve performance? In theory, yes. In practice, maybe.
The biggest potential win here is that you could run many threads that can run I/O in parallel. In Node.js/V8 you only have one native OS thread while in C++ you can put many native threads to serve the I/O sockets. It's quite a lot cheaper to change from one thread to another than it is to change from one process to another (if you have many node.js processes running) so there is potential for performance increases if you have some CPU-heavy stuff in your code. Or you have more sockets/requests to serve than a single CPU is capable of.
This is assuming that libuv and node.native don't have anything that would inhibit running in multiple threads. The system calls running underneath (read, write, epoll/kqueue) are thread safe, but libuv/node.native may have something that isn't. I didn't double-check.