>>>>> "CO" == Chas Owens <[email protected]> writes:
CO> On Sat, Aug 29, 2009 at 23:21, Uri Guttman<[email protected]> wrote: >>>>>>> "CO" == Chas Owens <[email protected]> writes: >> >> CO> On Sat, Aug 29, 2009 at 21:12, Uri Guttman<[email protected]> wrote: >> CO> snip >> >> SB> ... in my case, it's not feasible given that I need an object maintained, >> >> SB> that is relatively complex in nature. >> >> >> >> you would be surprised at how much data you can put in a hidden >> >> variable. just convert it to text with dumper and store it there. html >> >> forms can send tons of data. >> CO> snip >> >> CO> If the data is sensitive, you don't want to transmit it in this way. >> >> you can use shttp and send anything. cookies are better but it would work. CO> snip CO> I don't mean eavesdroppers, I mean the client should not be able to CO> see the data. Never send data to the client they should not have. CO> Encrypting the data (apart from https, which only encrypts the CO> transfer of the data) might be good, but that is extra work. And why CO> transmit anything to the client that the client doesn't need? CO> snip >> CO> What? This is what shared memory is for. It is available on all >> CO> modern UNIXes, and I think it might be available on Win32. There are >> CO> modules in CPAN that make it easy to use: >> >> it isn't shared except between processes or on disk. he specifically >> asked about shared ram that stays resident outside of processes. CO> snip CO> Shared memory is external to any process. No process needs to be CO> running for it to exist. Did you look at the code sample? You run CO> the program the first time and it creates a chunk of shared memory, CO> prints out a key that lets you get back to that memory, puts some CO> stuff in it, then exits. No process is running at this point. Then CO> you run the program again with the key given by the first run, it CO> access the memory, prints the contents, then destroys the memory CO> (because otherwise it will keep existing until you reboot). 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) >> lower level stuff works that way. you can mmap in a file into a process >> and so can other processes at the same time. all writes to the mapped >> virtual ram will be backed by disk so it is persistant. of course you >> still need to deal with locking and such. it wouldn't work in perl >> easily due to memory not being fixed in virtual space as perl can >> realloc as it wants to. this is easily done in c. CO> 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) CO> to have the memory backed by a file (it is often used to read files CO> more efficiently) and that the memory does not outlive the process. CO> Shared memory on the other hand is just a chunk of memory with a name CO> that can be used by processes that know its name. It is persistent. CO> If your code doesn't clean up after itself, the memory will stay CO> allocated until the machine reboots. I lost about 300 bytes of memory CO> to bad code (I forgot to print the key the first time, and a couple CO> other things went wrong that I don't remember) while writing the CO> example. I won't get that memory back until I reboot. This points to CO> a big danger to using shared memory. If you screw up you have real CO> memory leaks that can only be fixed by rebooting. 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. 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. uri -- Uri Guttman ------ [email protected] -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com --------- -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] http://learn.perl.org/
