>>>>> "SB" == Steve Bertrand <st...@ibctech.ca> writes:
SB> I believe my own confusion has led to portraying my confusion quite well. SB> Let's forget what I've stated up until now. I'll do some homework, and try SB> to get a better understanding of the term 'persistence'. fwiw, my SB> understanding of 'persistence', is ``maintaining the consistency and SB> accuracy of data between separate and different processes''. no need for consistancy or accuracy. just maintaining data is enough. if you can't maintain data with consistancy or accuracy you ain't maintaining data! >> please >> ask about the actual problem and not what you think is the proper >> solution. SB> My apologies. I had gotten ahead of myself. a common problem with newish programmers. stick to real problems and you will get real solutions. >> we can solve it better and faster if we tackle the real >> problem and not some wild goose chase you are already upon. >> SB> For instance, I have a Perl program that generates a hash of SB> numbers. This program needs to exit completely before another SB> program loads about a second later, and retrieves the data. In SB> this case, the first program has no way of passing the hash to the SB> second as a parameter. huh?? why can't one program just call the other? is there a realtime constraint? >> there are many ways to handle persistance between cgi calls. you can use >> hidden variables in forms, 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. >> build links with values in the urls, use >> cookies and sessions, etc. SB> I'm not a programmer, particularly not a web programmer, and I really SB> don't want to learn about cookies and sessions... much easier than your proposed solutions! cookies can all be done with existing modules. same with sessions. and there are plenty of perl/web frameworks which do all of this for you. i mean ALL of it including persistance. >> there are many modules which help with all of >> those and more. you are reinventing a very round wheel! :) SB> Many have advised with numerous CPAN-available modules that will SB> do what I want to do. I've been reading up the perldoc on all of SB> them. perldoc is for your installed perl and modules. you need to scan cpan to find all those other modules. >> persistance is not a function of how it is stored in memory but how you >> keep the data alive between seperate processes. 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. SB> I'll use the info that I've been given to solve my current _issue_, and SB> focus my time on the fundamentals. I'll try to stick with what can't hurt SB> me if I 'leak' on it until I gain more experience... change the issue away from persistance in ram as it is not possible. think about it, who would OWN the ram? ram is allocated in a processes virtual space so how could it live outside a process? you don't want to have kernel space as that would be a security hole. shared memory is always backed by disk store as well so it is never just in ram. 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/
