4 ms·

> By choosing node you are choosing single-threaded async IO as your primitive In node is it very easy to fork processes and have them communicate. Scripting l

> By choosing node you are choosing single-threaded async IO as your primitive In node is it very easy to fork processes and have them communicate. Scripting languages for serving HTML and JSON aren't the place for threads. Node now offers sync versions of most IO functions as well.

kotxig 7y ago
You just don't have shared memory at your disposal by forking processes. For example, having a rather large dictionary of translation strings which are read-only and static, you have to load these in every process as there is no copy on write property to these "forks". If your JSON payloads are large, you can't have a forked process do the deserialization of it (because you would need to re-serialize across the communication boundary, which defeats the point). I think it would be reasonable to have immutable data structures shared with web workers. I also think it would be reasonable to make it possible to pass complex objects (all primitive types supported by JSON) between workers without a serialization step.
laurencerowe 7y ago
Running multiple processes doesn’t solve the head of line blocking problem where a single large request causes all the small requests behind it to pile up increasing their latency too. When you have thread pools this is not a problem as each request is processed by the next available worker. JS has nice fast runtimes, and crucially the ability to share code between client and server. I think there’s potential (even without threads) to have a JS server architecture that does not require the entirety of a request/response to be processed in a single thread but could break it up so it could be processed by a pool of workers at IO event boundaries. Either as one isolate per request or explicitly passing state for IO event callbacks.

4 ms·

> By choosing node you are choosing single-threaded async IO as your primitive In node is it very easy to fork processes and have them communicate. Scripting l

by justinmeiners 7y ago

kotxig 7y ago
You just don't have shared memory at your disposal by forking processes. For example, having a rather large dictionary of translation strings which are read-only and static, you have to load these in every process as there is no copy on write property to these "forks". If your JSON payloads are large, you can't have a forked process do the deserialization of it (because you would need to re-serialize across the communication boundary, which defeats the point). I think it would be reasonable to have immutable data structures shared with web workers. I also think it would be reasonable to make it possible to pass complex objects (all primitive types supported by JSON) between workers without a serialization step.
laurencerowe 7y ago
Running multiple processes doesn’t solve the head of line blocking problem where a single large request causes all the small requests behind it to pile up increasing their latency too. When you have thread pools this is not a problem as each request is processed by the next available worker. JS has nice fast runtimes, and crucially the ability to share code between client and server. I think there’s potential (even without threads) to have a JS server architecture that does not require the entirety of a request/response to be processed in a single thread but could break it up so it could be processed by a pool of workers at IO event boundaries. Either as one isolate per request or explicitly passing state for IO event callbacks.