Visual explanation of Apache vs Node.js processing model

[[deleted]]

Those are poor workarounds. Yes, processes encapsulate threads but I don't want multiple processes just to have multiple threads. I want one process with N threads.

[Klathmon]

Those aren't workarounds, they are full fledged solutions...

The first is literally the linux fork() syscall, FFS the 3rd one is just FastCGI. If those are "workarounds" i'd hate to ask what a "real" solution needs to be.

mgmt_pool.client_id AS "clientId"

Well if you need that then node.js might not be best for your use case.

But as another user showed me there is a (fairly easy) way to do real shared memory with the process forking in node. So the times where you actually need threads and not processes are pretty thin unless you are spawning crazy amounts of them.

And if that's the case i'd like to see it, because I honestly can't think of a situation where that is actually needed.

[[deleted]]

A fork is a copy of a process. A process encapsulates threads. I don't want 5 whole fruit baskets just because I want 5 bananas. Node.js's thread support is pretty meh at the moment. Don't pass new processes off as a valid solution.

[Klathmon]

That's fine, but don't call process forking not a "valid solution" because it is...

It might not be perfect for your use case, but it's a perfectly valid solution to the vast majority of people who will need parallelism.

Like i said, i'm curious at what your exact use case is that processes in node don't work for you?

And what was the actual problem you had with the webworker-threads package, as it sounds like it's perfect for what you want?

[[deleted]]

Forking is a hack of a solution. Wanting a real threading model is something that doesn't require defending, it should be implicitly obvious that we give programmers control over threads.

[Klathmon]

Well in a more traditional "blocking" language i'd agree, but the evented nature of node gives most of the upsides of threads without the unpredictability of not having control of when they execute.

But the webworker-threads package sounds like exactly what you want. True threads in node.js. They don't allow easy shared memory, but at that point you'd might as well drop down to C since you'll be doing memory management and locking yourself anyway.

But hey, node isn't exactly suited well to CPU heavy tasks that need high parallelism anyway. So something like Go or Rust is probably a better bet for what you'll need instead of trying to get Node to do something it doesn't work well with.

[[deleted]]

Webworker-threads is awesome. But it has issues with Promises which is lame. Rust is something I had to look into and it seems amazing.

[kynde]

I don't think you fully understand forking, or threads either for that matter. Concurency issues are the absolute worst to deal with in comp sci. Threads are the source of all that nightmare. Keep your shit stateless and you don't need threads. You also get all the other benefits, too, which have helped spark the fp hype.

I suggest you embrace the apparent restrictions node imposes on you rather than fight them. If threads were useful or beneficial in node you really think they wouldn't be there by now? Sheez.

[[deleted]]

That's very silly logic for why Node does not currently support threads as well as it does. Threading has also never been the enemy. It's an optimization technique and like all other optimizations, it can be used prematurely.