Feedback about Workers!

[addaleax]

Hi everyone! Something that starts coming up more and more frequently is moving Workers out of experimental status; we’re tracking that in nodejs/node#22940.

Something that would be very helpful is having feedback from people who use Workers, build libraries on top of it, or can share experiences with the API. Please use this thread for that! Whether you feedback is positive, negative, or anything else, it’s always going to be helpful as long as it’s on-topic.

If you have requests about specific changes you’d like to see, other than moving out of experimental status, feel free to comment here or open an issue at https://github.com/nodejs/node.

[wilk]

Woah, I missed this post! That's great!
And of course thanks for your work on Node.js worker threads! I think they are the missing piece of Node.js platform 💪

Here's my feedback.

I'm the author of microjob, a tiny lib built on top of Node.js worker threads.
The purpose of this lib is to simulate the GoLang's lightweight threads, called goroutines.
Please, take a look to this example to get the idea: goroutines
Basically, it provides a way to execute some parts of the program into another thread, sharing the runtime context with ease.
For instance: https://play.golang.org/p/D4yU5ndG8bR

AFAIK, on Node.js things are different.
Usually, worker threads are spawned ahead, in a static separated file, as suggested inside the docs.
In my case, I needed to be able to send user defined dynamic piece of program to an empty worker thread, providing the user the ability to put in background some heavy CPU load ops, executed in a custom runtime context.

So, I found that there are two ways to pass something to worker threads: via message passing (strings, postMessage) or shared array buffer.
The first one can be achieved using v8 serialize and deserialize or via JSON.stringify/JSON.parse.
The second one is a little bit trickier because it needs you to convert your something into a buffer.

Now, both approaches do work for data and that's great.
However, the situation is quite different with runtime context, such as class instances (both custom and native).
For instance, I would like to pass a new Date() instance (not the stringified version) from the main thread to the worker.
Another example: I've my Person class defined in the main thread with both static and instance methods/props and I want to be able to call them inside the worker.
Remember that microjob cannot access the source code of the main thread so the only way (I've found) is to pass the context using postMessage.
I've also opened an issue on Node.js Help repo: nodejs/help#1558

So, I would ask to have an easy way to pass and execute runtime context (maybe in conjunction with vm.runInContext ?) as I do with GoLang.
Here is an example of runtime context used in microjob.

Another thing I'd like to ask: microjob implements the thread-pool pattern and I think it would be cool having it built-in.

Thanks again and keep going this way! 🔝 💪 👏

[Akamaozu]

Edit: Foiled by daylight savings.

1. Read this

#6 (comment)

2. Then This

Recently streaming myself working on a system where one node.js process coordinates with a second one via message passing.

Start at 3m35s .. you should get the main gist by 10m

https://www.twitch.tv/videos/330954507?t=3m35s

[wilk]

@Akamaozu

microjob uses a worker pool to avoid performance issues in spawning new threads for each new execution.
Your suggestion entails microjob to spawn a new worker for each job call, breaking the above feature.

Further more, passing class instances to the workerData does not solve the problem because it uses the same v8 algorithm to serialize/deserialize data.

Quoting from the docs:

workerData Any JavaScript value that will be cloned and made available as require('worker_threads').workerData. The cloning will occur as described in the HTML structured clone algorithm, and an error will be thrown if the object cannot be cloned (e.g. because it contains functions).

[Akamaozu]

@wilk

You don't need to spawn a new process per job.

Spawn the worker, then feed it work via a queue like Rabbitmq.

Most queuing systems should have a way to control concurrency, so you can limit it to X level of concurrency per worker.

[wilk]

@Akamaozu

I was talking about spawning new threads, not new processes.
Spawning new threads is more expensive than feeding existing ones.

Maybe the following example can explain the situation better:

class Person {
  constructor(name) {
    this.name = name
  }

  hello() {
    console.log(`hello from ${this.name}`)
  }
}

const foo = new Person('foo')

// passing it to an existing worker thread
job(() => foo.hello())

Now, I don't want the user to define and instantiate Person inside job call nor inside a worker thread separated source file.
The user should be able to pass the source of the action to perform (like the foo.hello()) and the corresponding context.

For instance:

job(() => foo.hello(), {ctx: {foo}})

I think that the same serialization/deserialization problem applies to your case (feeding via a queue).
Further more, I don't want the user to be tied to an external service (like RabbitMQ).

[Akamaozu]

@wilk

Another option might be to send the program to the data, instead of the other way around.

This means:

• Data starts off in the worker

• the remote place where the object originally was (call/creation site) is now original call site.

• original call site sends messages to worker to do x on data, which it does and sends results back to original object creation site.

Now you can work on objects remotely.

[Akamaozu]

@wilk Ok let's use your example

var data = {
  class_path: "./class/person.js", 
  init_args: [ "foo" ],
  action: "get-foo"
};

job( data, ( err, foo )=> {
  // use result
});

[wilk]

@Akamaozu

The internal state of a class instance may vary in time and it does not only depend on initial args.
You should provide something like event-sourcing to reproduce the actual state and this is too much effort to put on the user shoulders.

[Akamaozu]

@wilk we are entirely in agreement here 👍

1. Been working on taking the load off user's shoulders here
   https://github.com/akamaozu/node-supe

2. You can play with a live demo of code using this.

   • clone https://github.com/Akamaozu/workshop-satellite
   • configure your instance via .env file
   • run cloned workshop-satellite
   • view results at https://torontojs-basestation.herokuapp.com

Things to note about the demo

- brain doesn't touch any of the files being moved around. it sends instructions and the other node.js process works with the data, similarly to what you're describing.
- you can see what the application is doing via console.
- demo's interactive. kill processes and see what happens.

[Akamaozu]

Can't assume you'll be interested in spinning it up to check, so I took a screenshot of some log output.

Red is where brain instructs other node.js processes to do work.
Green is them doing the work and logging it.

[devsnek]

@wilk It isn't possible to actually share the runtime between two workers. JS's prototype design makes it pretty much untenable to share any object between two threads (with the exception of SharedArrayBuffer, which works because we can perform atomic operations on it)