docs: add note about using cluster networking-less

[pimlie]

Although the primary use-case for the cluster module is networking, the module provides a generic master/worker interface that could also be used if you dont use networking at all. Currently the docs are a bit ambiguous about this as only the primary use-case is ever mentioned, this remark should clarify that the cluster module can also be used without disadvantages if you dont use networking.

Refs: nodejs/help#970

Checklist

• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

doc

[devsnek]

networking-less is kinda awk, maybe just without networking

[pimlie]

Thanks, you are probably right. Changed both the commit as the commit message

[pimlie]

@Trott Strange, I received an email with your comment about not thinking that networking is the primary use-case for cluster but don't see your comment listed here on github?

The main reason I wrote that networking is the primary use-case is because I have been startled by the current documentation for weeks and @bnoordhuis confirmed this in the referenced nodejs/help issue. Maybe otherwise the Cluster docs could use more of an overhaul then just adding this sentence?

Let me give you a few examples of why I think the current documentation is quite ambiguous if networking isn't the primary use-case:

• The first/introduction paragraph says The cluster module allows easy creation of child processes that all share server ports. To me this is much more a statement then an introduction for the listed example that uses networking. Although nowhere is said that you can only use cluster with networking, it also doesn't specifically state the inverse which could imply that only the listed example use-case is supported. Hence the ambiguity.

• Under How It Works again except for the first sentence this whole paragraph only talks about incoming connections and how they are shared between workers. And as this is the only thing that's talked about, it doesnt leave much room to the reader for a use-case without networking.

• Options like schedulingPolicy or events like listening that only apply to networking are not labelled as such. Of course it is implied and it may even be trivial that they are, but as I said before whats trivial for one may be inconclusive for another. Especially in the bigger picture of the cluster docs as a whole

Not sure if this translates correctly to English, but in Dutch we say All pilsner is beer but not all beer is pilsner. I guess you could say that currently the cluster docs only talk about pilsner (with networking) while it applies to all beers (without networking)? 🍻

[gireeshpunathil]

I guess the primary use case for cluster is to attain vertical sclability (in-system) to suppliment any short-comings the single-threaded node has in exploiting the multiple cores in the host, and as the primary use case of node is web workload, the cluster naturally inherited it. Nothing stopping one from using cluster for other purposes such as massive computation in a distributed manner. The doc changes looks good to me, thanks!

[Trott]

@pimlie OK, you convinced me. I never thought of it that way, but the docs seem to make that assumption.

(You didn't see my comment on GitHub because I deleted it immediately after leaving it. I realized I probably wasn't adding a whole lot to the conversation with my question so I deleted it. I guess GitHub sends notifications immediately because the comment was probably there for a matter of seconds. Oh well. Lesson learned.)

[Trott]

Nit: remove "all" as certainly there are use cases where it is not the right choice.

I'd probably strip it down further to:

Although a primary use case for the `cluster` module is networking, it can
also be used for other use cases requiring worker processes.

[pimlie]

Thanks, sounds better indeed!

[pimlie]

Updated as per @Trott comments

[addaleax]

Landed in adb7be2, thanks for the PR! 🎉