

Shared memory with Node.js - vpj
http://blog.varunajayasiri.com/shared-memory-with-nodejs

======
optimusclimb
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.

------
ndesaulniers
Without locking primitives this is asking for data races.

~~~
michaelsbradley
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
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
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
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
This is probably a good start:

[http://hypirion.com/musings/understanding-persistent-
vector-...](http://hypirion.com/musings/understanding-persistent-vector-pt-1)

