3 ms·
I admit both of them have lots to say about SSJS or even SS-anything. Still I can't understand Bruno's sentiment towards thread-per-request approach, considerin
by kunley 16y ago
I admit both of them have lots to say about SSJS or even SS-anything. Still I can't understand Bruno's sentiment towards thread-per-request approach, considering that he's talking about the Node here. Node.js is all about a simplicity of evented, single thread design. If someone thinks this "worse is better" approach went too far in this case, why to use Node at all? There are tons of good thread-based solutions nowadays - a fit for anyone's taste.
- jchrisa 16y agoThe issue is that a single V8 thread in Node.js could be handling the event loop for thousands of clients. A process crash here could cause a mini thundering-herd when all the users attempt to reconnect at the same time. So his question is not baseless - the solution is to have a VM that rarely crashes. n.b. Erlang also hard-crashes when it can't allocate memory. This hasn't hurt its reputation for reliability.
- jasonhoffman 16y agoYes, Bruno's fundamental point is that "desktop" language VMs will just end a process when there's memory allocation errors. So basically there has to be real means to instrument and error handling has to be robust, he's correct in this assertion.
- mraleph 16y agoA process crash will cause the same problem for thread-per-connection server. There is essentially no difference in stability between thread-per-connection and event-loop based servers.