in reply to Re^7: Defining global variable in a subroutine
in thread Defining global variable in a subroutine

choroba ,

Never. Only children process the global hashes

"Well done is better than well said." - Benjamin Franklin

  • Comment on Re^8: Defining global variable in a subroutine

Replies are listed 'Best First'.
Re^9: Defining global variable in a subroutine
by choroba (Cardinal) on Feb 23, 2012 at 10:38 UTC
    Ok, so where does a child access a piece of the global hash changed by a different child? If each child works only on its own copy of the global hash, Eliya is still right (and he really is).
[reply]

      This doesn't make any sense!

      If child#1 answers the 'login' call for the account and creates the account HoH in it's own child#1's address space, then how does child#4 access the information?

      During testing, the children real/virtual memory didn't change, but the parents real/virtual memory expanded and contracted based upon load(number of users ). By using the in-memory hash, we increased performance significantly depending on operating system over using a DB to store the information.

      Could JavaFan explanation have been accidentally activated by the way we wrote the application?

      The application can't work without sharing the data between children. And the application does work!

      Thank you

      "Well done is better than well said." - Benjamin Franklin

[reply]
        Could JavaFan explanation have been accidentally activated by the way we wrote the application?
        I've no idea which explanation you are referring to.

        But if your application "works", it doesn't work in the way you think it does. Forked processes do not share data*,**. Not on the OS level, and certainly not on Perl level. If you think otherwise, it will be easy for you to present to us a short, stand alone piece of code that proves different. Until you do so, I will refuse to believe you.

        *There's a level of indirect sharing. If you have open file descriptors when forking, the OS will give the child and parent their own copy of the descriptors -- but the descriptors will still point to the same file pointer. That's why you often see children close one or more of STDIN, STDOUT or STDERR after forking.

        **Well, for the past couple decades, OSses usually use copy-on-write when forking, so process may "share" data (or rather 'memory pages') that neither of them have written to. But this is just a pointer trick deep in the bowels of your OSses memory management.

[reply]

In Section Seekers of Perl Wisdom