5 ms·

Node is single-threaded, so yes they are shared. Requests are basically just multiplexed inside the same message loop. In my opinion it wouldn't be quite as s

Node is single-threaded, so yes they are shared. Requests are basically just multiplexed inside the same message loop. In my opinion it wouldn't be quite as scary if js didn't make it so damn simple to accidentally define a global variable (like in this instance, where it was never actually declared in globally-scoped code).

bzbarsky 15y ago
Why does threading matter? You can have multiple JS global objects all running on the same thread. See any web browser.
- pbz 15y ago
  JS in browsers is not multi-threaded. There's only one JS thread where requests from async calls are queued: http://ejohn.org/blog/how-javascript-timers-work/ http://ejohn.org/blog/how-javascript-timers-work/ When dealing with true multi-threading you have all sorts of issues you need to worry about, like locking for writing, worrying about deadlocks, etc. that make coding much more difficult.
  - bzbarsky 15y ago
    Yes, I know JS in browsers is not multi-threaded. It runs multiple globals all on the same thread, as I said. Node is not multithreaded either; it could run a bunch of separate globals on the same thread as well, if it wanted to.
- allertonm 15y ago
  Indeed you can - but I suspect I know why Node has avoided this. If you did take advantage of the runtime's support for multiple global objects, what would those global objects correspond to? The most natural scope would be "user session" - but if you go that route, now you support stateful user sessions. And before you know it you have developers storing loads of user session state in the server's RAM and wondering why they keep running out - and lose the ability to easily fail over to another server process. So I imagine Node's author decided it was better to just keep things simple and discourage use of globals.
  - bzbarsky 15y ago
    "user session" is tough, indeed. But doing global per request would not be that complicated, if desired.
- dbattaglia 15y ago
  Well I don't think web browsers are really the same thing as server side code. Even individual pages in a browser are sandboxed from each other. Just like individual request/response cycles for a user session probably should be on the server (unless you go out of your way to break that, ie making some variable "static").
  - bzbarsky 15y ago
    My point was that nothing inherent to JS forces sharing of a single global object across everything you do. The embedding (Node in this case) fully controls the granularity of such sharing.

bzbarsky 15y ago

Why does threading matter? You can have multiple JS global objects all running on the same thread. See any web browser.

pbz 15y ago
JS in browsers is not multi-threaded. There's only one JS thread where requests from async calls are queued: http://ejohn.org/blog/how-javascript-timers-work/ http://ejohn.org/blog/how-javascript-timers-work/ When dealing with true multi-threading you have all sorts of issues you need to worry about, like locking for writing, worrying about deadlocks, etc. that make coding much more difficult.
- bzbarsky 15y ago
  Yes, I know JS in browsers is not multi-threaded. It runs multiple globals all on the same thread, as I said. Node is not multithreaded either; it could run a bunch of separate globals on the same thread as well, if it wanted to.
allertonm 15y ago
Indeed you can - but I suspect I know why Node has avoided this. If you did take advantage of the runtime's support for multiple global objects, what would those global objects correspond to? The most natural scope would be "user session" - but if you go that route, now you support stateful user sessions. And before you know it you have developers storing loads of user session state in the server's RAM and wondering why they keep running out - and lose the ability to easily fail over to another server process. So I imagine Node's author decided it was better to just keep things simple and discourage use of globals.
- bzbarsky 15y ago
  "user session" is tough, indeed. But doing global per request would not be that complicated, if desired.
dbattaglia 15y ago
Well I don't think web browsers are really the same thing as server side code. Even individual pages in a browser are sandboxed from each other. Just like individual request/response cycles for a user session probably should be on the server (unless you go out of your way to break that, ie making some variable "static").
- bzbarsky 15y ago
  My point was that nothing inherent to JS forces sharing of a single global object across everything you do. The embedding (Node in this case) fully controls the granularity of such sharing.