>>>>> "CO" == Chas Owens <chas.ow...@gmail.com> writes:
CO> On Sat, Aug 29, 2009 at 21:12, Uri Guttman<u...@stemsystems.com> 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> snip >> SB> Understood. Rephrased: I want to keep data alive in some fashion, *in >> SB> memory* between processes. >> >> that is your bugaboo. can't be done. period. memory only exists inside a >> process on typical OS's. so stop thinking like that as it is the XY >> problem again. your problem is persistant data between processes but you >> think it is persistant data in ram between processes. you are caught up >> in a solution direction and painting yourself into a corner. 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> And even if you don't use shared memory, there are lots of in memory CO> databases such as memcached that are easy to use. There is no need to CO> resort to slow disk if you need fast memory. again, that is a process. i only said you can't do what he asked for without processes or disk. the OS can't offer shared ram without them or there be dragons. CO> Okay, maybe I am exposing my ignorance, but I have never heard of CO> shared memory being backed by disk. The whole purpose of shared CO> memory is to allow multiple processes to access the same chunk of RAM. 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. uri -- Uri Guttman ------ u...@stemsystems.com -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com --------- -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
