High level architecture

[refack]

Follow up to #1

If we consider the use-cases brought up in Step 1) Figure out use cases what should be the high level architecture?
_{Let's try to consider pros and cons and not just bikeshed 😉}

Some options that were brought up in nodejs/node#13143:

1. Multithreading - workers: initial implementation node#2133 and node-webworker-threads
2. Multi process with mutable shared memory - Tracking issue: Worker support node#13143 (comment)
3. Multi process with immutable shared memory and serialized communication - Tracking issue: Worker support node#13143 (comment)
4. Multi process with only serialized communication

[refack]

Considering @bnoordhuis comments on the complexity of multithreading, and based on personal experience, personally I'm pro multi-process. IMHO it seems like a the more natural solution for JS in general and nodejs in particular.
Intuitively I would vote for option (3), but I'm not sure how well it serves the "parallelize heavy computation" use case over option (2)...

Pros for (3):

• IMHO simplest to implement
• Covers the "utilize multi core" requirement
• Could fulfill the "prioritize main thread over Workers" requirement
• Immutable shared memory fulfills the "efficiently share large amount of data" requirement (although only one way)

Cons for (3)

• Depends on OS for IPC and shared memory (platform specific code fragmentation)
• Necessitates a mechanism for loading/sharing code
• Multithreading could be considered simpler to grok and use
• Necessitates implementing immutability of shared-memory, and implementing efficient communication protocol.
• Probably more memory intensive.

---

I'll be happy add to this list based on future comments.

Some biased refs off the top of my head
python's GIL
Chromium's multi process architecture

[refack]

@addaleax too soon?

[addaleax]

I think a more reasonable next step would be to figure out whether what we’re going for is exposing a full Node API, or just a reasonable minimum that doesn’t include things like I/O (which is part of the reason why I was starting by asking for use cases).

If we want a full Node API in Workers, yes, multi-process probably makes the most sense. But I’m not sure whether that’s a good idea; I would very well imagine that using parallel workers to do more I/O would be considered an anti-pattern. It would also make the lifes of those easier who would want to use Workers for script isolation.

[refack]

Ack. That's why I didn't call this "Step 2".
But it was on my mind, and was discussed in nodejs/node#13143...

[vkurchatkin]

I think a more reasonable next step would be to figure out whether what we’re going for is exposing a full Node API, or just a reasonable minimum that doesn’t include things like I/O (which is part of the reason why I was starting by asking for use cases).

I think we need both modes.

[refack]

Your comments made me realize I had an hidden assumption that we are planning to comply with the Web Worker API. But I realize that's TBD as well. Thank you 👍

[icodeforlove]

@refack I think it would be great if we could conform to the Web Worker API, would be less of a learning curve, and they have already solved most of the things we would be doing. Like you mentioned before we already have non-standard things like cluster, and fork.

The big advantage of Workers would be a standardized performant way of utilizing all cores and interfacing with large ArrayBuffers.

[addaleax]

Note that providing the WebWorker API and a full Node API aren’t necessarily mutually exclusive; I agree, having the former is very likely a good idea.

[vkurchatkin]

IMO implementing WebWorker API should be a non-goal. It could be easily implemented in userland on top.

[domenic]

FWIW the language spec these days has a built-in model of "agents" and "agent clusters" which are meant to represent threads and processes. SharedArrayBuffers can be shared between agents, but not between agent clusters.

[NawarA]

I believe we should allow for an architecture that allows for horizontal, peer to peer messaging. Basically, let's have the ability to postMessage to any event loop. Today, we can send a message from Master to worker, but workers should be able to communicate directly with other workers.

If we can do this, and add shared memory between event loops using the shared array buffer (available in 6.0), I think that's a big win for the kind of software architectures we'll enable others to create. It'd be a big deal

[refack]

It'd be a big deal

It's definatly worth thinking about. I'm just thinking how will the workers identify each other 🤔 (know if the other side is there/responsive/alive)...
@NawarA Do you have a use case in mind? (Re #1 )

[stevenvachon]

https://github.com/GoogleChrome/tasklets

[rtfeldman]

Anecdotally, I'm using child_process.fork for the elm-test CLI, and avoiding the per-message IPC cost would be a big deal to me!

For my use case, any design that allows computation across multiple cores with less message-passing cost than IPC is 😻, and anything with the same (or more) message-passing cost than IPC means I'd just keep using child_process.fork. 😄

Not having to spawn separate processes (which only (1) would avoid) would be nice, as spawning processes contributes to overall execution time whenever someone runs elm-test, but it's not a huge deal.