5 ms·

Shared memory with Node.js

• ndesaulniers 11y ago
  Without locking primitives this is asking for data races.
  • michaelsbradley 11y ago
    The use of immutable collections[1] could help, but at some point in most programs it will be necessary to synchronize "pieces of state" across processes/threads. Perhaps a high-level API for doing so could be adapted from Clojure's STM facilities[2]? [1] http://swannodette.github.io/mori/ http://swannodette.github.io/mori/ [&] http://facebook.github.io/immutable-js/docs/ http://facebook.github.io/immutable-js/docs/ [2] http://clojure.org/concurrent_programming http://clojure.org/concurrent_programming
    • ndesaulniers 11y ago
      If you make copies of immutable data collections to change state, why not just use message passing? If you're going to share memory, you're more likely to write lock free data structures than copy immutable collections around. Supposedly, the point of juggling razors is for speed.
      • michaelsbradley 11y ago
        Immutable collections don't have to be wholly copied – derived collections may share internally quite a bit of information with the original collection/s. That allows them to be both fairly efficient and yet safe when used across concurrent processes. The "tricky party" is when concurrent processed need to synchronize some reference. Facilities for such ops can be orthogonal to the implementation of immutable collections, and then the two can be used together to good effect.
        • ndesaulniers 11y ago
          That's interesting, I did not know that. While it sounds like a fair amount of work, it can't be too much more than designing lock free data structures. Do you have good references to the design of such structures, or should I follow the links you posted above?
          • michaelsbradley 11y ago
            This is probably a good start: http://hypirion.com/musings/understanding-persistent-vector-pt-1 http://hypirion.com/musings/understanding-persistent-vector-...
• optimusclimb 11y ago
  While of course I appreciate the ingenuity here...at what point does doing something like this with node just become trying to force a square peg into a round hole? Node is great for squeezing performance out of a box saddled with io bound tasks, or handling a large number of mostly discrete connections, that don't share a ton of state. If you need access to something like a cache where synchronization is not a major issue, and you don't want to dupe memory across the processes, you can throw something like redis on the box. However, if what you really want shared memory across what are now essentially threads...why wouldn't you go to a technology that's been designed for the task? I'm referring to the likes of Java, Scala, golang, etc.