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

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

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

Replies are listed 'Best First'.
Re^11: Defining global variable in a subroutine
by JavaFan (Canon) on Feb 23, 2012 at 11:46 UTC
    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.

      JavaFan,

        I've no idea which explanation you are referring to.

      You referred to a way to share variables using Exporter. What I was referring to was the possibility that we accidentally created an environment that worked because Exporter was used by one of the applications that we used. It was only a guess.

      I will try to find a script that demonstrates the sharing.

      Thank you

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

        Exporter has nothing to do with forking. Exporter is a way to share symbols between modules. It does not facilitate sharing data between processes.