On Sun, Aug 30, 2009 at 00:46, Uri Guttman<u...@stemsystems.com> wrote: snip > my memory of shmop is old. it does have kernel persistance but that > doesn't do any good for http persistance if the kernel is rebooted > between requests. you still need disk persistance. this is from > shm_overview on linux: > > POSIX shared memory objects have kernel persistence: a shared > memory object will exist until the system is shut down, or until > all processes have unmapped the object and it has been deleted > with shm_unlink(3) snip
Yep, as I said repeatedly shared memory only lasts until reboot. However, I am assuming that the data is some sort of configuration object that could be recreated on start up. It would be trivial to add a script to /etc/init.d to dump a given shared memory segment on shutdown and reload it on start up. If you are in a load balancing setup where it is acceptable for a machine to be rebooted while the site is up and running, neither mmap nor shared memory is an appropriate solution since they both are tied to a given machine. In that sort of setup you need a distributed cache like memcached. snip > CO> mmap is not shared memory; it is a modern alternative to shared > CO> memory. The two big differences are the ability (not the requirement) snip > > mmap is old (i used it over 20 years ago on sunos, way before linux even > existed). you could use it for shared ram backed by disk as it used the > vm for this. snip I never said it was new, just modern. Lexical filehandles are modern, but they are over ten years old at this point. mmap has mostly replaced shared memory and therefore is the modern alternative. snip > CO> You must serialize your data before you store it in shared memory as > CO> Perl won't just use it. At that point it is just a matter of making > CO> the shared memory segment the right size. And, as you can see for my > CO> example in an earlier email, there are modules that take care of that > CO> work for you. I would have used IPC::SharedCache, but it failed its > CO> tests on my machine, so I dropped back a layer. IPC::SharedCache > CO> takes care of the serialization step for you and provides a nice tied > CO> hash. > > perl is another issue and i already mentioned you can't directly deal > with memory since perl could realloc under you and screw up the > mapping. serializing is another story but you could use pack/unpack if > you wanted direct binary data. the format of the data is independent of > the sharing. snip pack and unpack are just another form of serialization, so I am not sure I understand your point (unless we are just saying the same thing). -- Chas. Owens wonkden.net The most important skill a programmer can have is the ability to read. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
