threads.js VS IncludeOS

Threads.js makes it pretty easy to spawn a thread pool and handle multi-threading workloads.

We did this via the npm threads wrapper and esbuild. We first moved all of our compute code into a new file with minimal imports, called imageCompare.worker.js. We then added a pre-compilation step with esbuild to compile this file into a bundle. We then spawn the worker using this generated file as a blob, and interact with it via the threads promise interface.

That latter one is in it's own process, and I also use multiple threads with the threads library.

This app has a memory leak where your worker threads are spawning out of control. You can verify this in Chrome DevTools Source tab: after you click the Generate button, you can see the worker threads spawning out of control until you close the process.

I'd advise that you do a better job at manually spawning and terminating the threads with the TFJS process. I've had success using this library in combination with TFJS: https://threads.js.org/

You can use it for everything. Even the compute tasks you can offload to worker threads using something like https://github.com/andywer/threads.js or you could create intensive modules in Rust and integrate using something like https://github.com/neon-bindings/neon

Web worker meets worker threads – threads.js\ (3 comments)

threads.js

So sad IncludeOS https://github.com/includeos/IncludeOS is no longer developed.

Nice! I wonder how well it will work with IncludeOS [0]?

[0]: https://github.com/includeos/IncludeOS

Also includeOS is a thing https://github.com/includeos/IncludeOS

IncludeOS can be used for that as well

FreeRTOS, Redox, IncludeOS (https://www.includeos.org/),...

IncludeOS – Run your application with zero overhead\ (7 comments)

I mean hell in c++ you can use #include and your binary will contain the operating system.