Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Disadvantages of using cluster api without any listening sockets #970
I was wondering if there are any major disadvantages of using the
It seems that at the moment the
To give a real-life example, currently I am using
So what is the general opinion about this? Should you only use the
Seem fine to me, no reason you couldn't or shouldn't use it that way.
As to whether it should be called out in the documentation, I'm leaning towards no. Documentation should be as simple and straightforward as possible. Docs that wander all over the place are terrible for getting things done.
Cluster's primary use case is networking because that's one of the biggest if not the biggest use case for node, so IMO it's proper that networking is what the documentation talks about.
Reasonable / unreasonable?
Thanks for your quick response. I looked at the cluster implementation but unfortunately wasn't really sure how child.js and a worker relate to each other. I guess child.js is used somewhere deeper within node. But is it correct there is no (or no major) overhead due to the networking part as that is only introduced once you really start listening for a socket? Afaik that overhead is only introduced once a worker has called listen() on the http/net api which will trigger the queryServer method?
I agree that documentation should be as simple as possible, but on the other hand you could say the docs are a bit ambiguous which is also not good. E.g. all the examples in the docs only speak indeed about Cluster's primary use for networking and even the name Cluster screams much more 'just for networking' then not. I would think that if you could use Cluster networking-less without any overhead/disadvantages a configuration option like
Maybe just a small note would be enough under How it works? Something like,
Just because whats trivial for one (probably you?) may be inconclusive for another (I guess me)
Correct. It's at its core just a wrapper around child_process with some builtin smarts for sending sockets across processes.
I can't promise it gets accepted but you're welcome to try a pull request.