4 ms·
If the other thread/process is running on a different machine (or you want to keep that option open) that's what you're going to have to do anyway though.
by fauigerzigerk 9y ago
If the other thread/process is running on a different machine (or you want to keep that option open) that's what you're going to have to do anyway though.
- amelius 9y agoYes, but that's a big "if". Sometimes you want to use a thread to keep the CPU from blocking (e.g. long database operations). Also, sometimes you want to use the CPU to its full capabilities.
- frutiger 9y agoDatabase access, likely the most common I/O operation from a web server, is certainly running in another process (or on another machine) - I'm not sure that "if" is as big as you suggest.
- fauigerzigerk 9y ago>Sometimes you want to use a thread to keep the CPU from blocking (e.g. long database operations). On the contrary. That's the prototypical use case for non-blocking event based IO. No threads needed. >Also, sometimes you want to use the CPU to its full capabilities. You can use all CPUs by using multiple processes. That's not an issue. Threads are useful when you want to run multiple algorithms in parallel on the same bigish in-memory data structure, especially one that has a lot of pointers. Something like an in-memory graph database or a desktop application that lets you work with huge files in-memory, or even complex user interfaces. For instance, I'm not convinced that the cross process bridging that React Native has to do is a great idea. So yes there are use cases where threads are very beneficial. But on the server side it's essentially the database/analytics systems themselves, not the code that accesses them.