A fun and efficient way to implement shared memory with minimum consideration for concurrent access would be for it to follow the stream.Duplex API. Like an 'in-memory' stream. That's pretty much how things like Go channels and ØMQ work, and it scales !
On Tuesday, 16 April 2013 19:38:52 UTC+2, Simon Majou wrote: > > Thanks for the info ! Medea & medea-clusterify are very interesting. > > On Tuesday, April 16, 2013 6:48:49 PM UTC+2, Kevin Swiber wrote: >> >> >> On Apr 16, 2013, at 6:57 AM, Simon Majou <[email protected]> wrote: >> >> Resurrecting this topic ... >> >> I think there is a real use case for node for shared memory. Because TCP >> connections are great but will always be slower than direct access to >> memory. >> >> To avoid any concurrency issue shared memory should be writable only by >> one process. When using the cluster module, the shared memory should be >> writable only by the master for example. If you want to write from a >> worker, just send a message, and the master will do it. >> >> >> On Thursday, August 12, 2010 8:24:30 AM UTC+2, Ohad wrote: >>> >>> I have few processes of Node, >>> What is the best practice of sharing memory between those processes ? >> >> >> I'd love to see cross-platform memory mapping in libuv with a JavaScript >> API in Node… but mostly because I'm hesitant to offer cross-platform native >> modules at this time. I still have issues getting the right ducks in a row >> to do a Windows compilation, so I feel bad asking others to do the same. >> >> Right now, the best memory mapping module I've seen is MappedBuffer[1] >> (See this PR[2] for v0.10 support). It delegates async operations to a >> thread using uv_queue_work (something the node-mmap module does not do). >> >> The module only works on POSIX systems, unfortunately. It would be great >> to have cross-platform support, but I'm not sure how easy it is to create a >> common API over both POSIX and Windows-based systems. >> >> I've been working on an all-JavaScript key-value store named Medea[3]. >> My initial experiment with memory mapping immutable files for the >> key-value store was very promising[4]. I'm still hacking on Medea, but the >> end goal is to use it as Web cache storage for an HTTP reverse proxy (which >> I am also still hacking on). This effort won't come close to touching >> something like Varnish without legit memory mapping, I'm afraid (not that >> it has to, but it would be pretty cool). >> >> I'm down for spending some cycles on a native module, but I'd likely need >> some assistance as I have a ton of conflicting priorities at the moment. :) >> >> [1] https://github.com/kazupon/node-mappedbuffer >> [2] https://github.com/kazupon/node-mappedbuffer/pull/1 >> [3] https://github.com/argo/medea >> [4] https://github.com/argo/medea/issues/10 >> >> Cheers, >> >> -- >> Kevin Swiber >> @kevinswiber >> https://github.com/kevinswiber >> >> -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
