Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re^2: Postpone garbage collection during a child process run?

by flexvault (Parson)
on Oct 06, 2010 at 18:38 UTC ( #863851=note: print w/ replies, xml ) Need Help??


in reply to Re: Postpone garbage collection during a child process run?
in thread Postpone garbage collection during a child process run?

Let me add some information to help the PerlMonks help me.

Why do I think it has something to do with garbage collection?

Since the use of the hash pointer did not cause a 'die', it must be still pointing at valid allocated memory. And when looking at the syslog entries, the pointer address at start of the subroutine and at the end of the routine is the same, as well as where it's pointing. However, after the return from the subroutine, the syslog entries show that the pointer address is the same, but it's contents (where it is pointing) is different, and that address points to the valid hash but without the changes made during the call to the subroutine. This looks like the hash was copied to a new location, and the old hash memory was placed on a free list, and not returned to the operating system.

I can only guess about this!

It seems, I was able to use the pointer before the copy completed, or some other type of race condition existed between garbage collection and my program. If garbage collection locked the hash, then the pointer wasn't updated until after I used it or when the subroutine returned ( since it looked like the subroutine was never called ).

If I am using the term 'garbage collection' incorrectly and a different term defines what I observed, please enlighten me.

Thank you

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


Comment on Re^2: Postpone garbage collection during a child process run?
Re^3: Postpone garbage collection during a child process run?
by Corion (Pope) on Oct 06, 2010 at 18:57 UTC

    What you describe is not what happens. You have a subroutine which triggers some action at a distance, namely, cleaning out a hash. You also seem to be quite confused when talking about references and what they reference, as you name them "pointers" and talk about "addresses". If you mean by "address" what you get when you print a reference (HASH(DEADBEEF)), then that is somewhat like a memory address, but you're better off treating it as a unique number identifying this particular hash.

    Perl has no processes running asynchronously to your program. There is no "garbage collection" process, and memory allocated to Perl data structures is only released when there is nothing more (in Perl space) referencing it. So you have a logic error in your program that has nothing to do with memory management at that level.

    Now, what could help us help you better was if you can show the relevant code that cleans out the hash contents and how you call it. Maybe it is something like this:

    sub foo { my %some_hash = @_; }; foo( %another_hash );

    Here, changes to %some_hash will never show up in %another_hash.

    But maybe you are passing around nested references like this:

    sub foo { my %some_hash = @_; }; my %another_hash = ( a_deeper_hash => { a => 1, }, another_deeper_hash => { b => 2, }, ); foo( %another_hash );

    Now, changes made to $some_hash{ a_deeper_hash } will change $another_hash{ a_deeper_hash }, as the copy of the hash is a shallow copy.

    My advice is this vague because you steadfastly refuse to show even what you see, the concrete debug messages and the code producing them, not to mention the code relevant to this. I understand that it's a tough task to remove more and more parts from a program that fails from time to time until you get to the input that makes it fail, but the only approach I know to accomplish is to reduce the input data until you find a dataset that always triggers the behaviour and then to start removing parts of the code, keeping only those parts that reproduce the error.

      "What you describe is not what happens."

      So you are calling me a liar?

      "You have a subroutine which triggers some action at a distance, namely, cleaning out a hash."

      Did I ever say this?   No!

      The top most subroutine does creation, modification, and destruction! All subroutines called use the hash for reference only. The subroutines use it to build html only. A static, read-only hash should not disappear!

      Your assumptions are just that -- ASSumptions.

      You want what I would like to have, a very small script that produced the problem. Life should be so simple.

      Perl has no processes running asynchronously to your program. There is no "garbage collection" process, and memory allocated to Perl data structures is only released when there is nothing more (in Perl space) referencing it.

      Thank you, I now can rule out 'processes running asynchronously'. You have finally said something of merit.

      Note: I have tried to ask intelligent, courteous and accommodating questions to this qroup. I don't know what I did to have such an aggressive response, maybe some-one is having a "bad hair day", but please if you don't understand the question, or you can't grasp the complexity of the problem, just don't respond!

      20101011 Janitored by Corion: Closed bold tag, as per Writeup Formatting Tips

        "What you describe is not what happens." So you are calling me a liar?

        No, Corion did not call you a liar. He did not even call you mistaken, confused.... what you describe is simply not how perl works, sorry.

        "You have a subroutine which triggers some action at a distance, namely, cleaning out a hash." Did I ever say this? No!

        Actually, that is exactly what you described, sorry.

        A static, read-only hash should not disappear!

        Can you show an example (real perl code) that creates a static read-only hash? I'll be happy to show at least two ways it can disappear (no c voodoo, just regular perl code).

        Your assumptions are ...Life should be so simple.

        Sure, someone with over 10 years experience could make bad assumptions, but we only have your descriptions as source material.

        Note: I have tried to ask intelligent, courteous and accommodating questions to this qroup. I don't know what I did to have such an aggressive response, maybe some-one is having a "bad hair day", but please if you don't understand the question, or you can't grasp the complexity of the problem, just don't respond!

        Please see http://perl5.git.perl.org/perl.git?a=search&h=blead&st=free&s=Corion. We've all been there, but try to remember the golden rule.

        PS perlmonks users have the option of using various themes so using colors doesn't always work out, see Writeup Formatting Tips

        I'm not calling you a liar. You seem to be just mistaken about what you observe, which is what I point out. There is no need to shout about this or use colorfull responses. If you want to continue to believe what you believe now, you can do that. I just don't think that this belief will bring you closer to a solution to your problems.

        If you don't like the assumptions I make about your code, maybe you can help me by showing more of your real code instead of your interpretation of your code? I think we are both convinced that your code does not behave as it should. You already have looked at your code and found no fault, yet there is a fault. Why do you think that your description of what you saw is accurate, as you did not see the fault? Of course, as I already told you, finding a small script that produces the problem is hard work. But if you don't want to do this work yourself, who else is supposed to do it?

        I think I can grasp the complexity of the problem quite well. My approach tries to reduce the complexity of the problem, but so far all I hear from you is "It's just too complex". This is not an approach that I think will lead to a solution.

        You seem to have a lot of misconceptions about how Perl works internally, yet you seem very eager to blame your problems on how Perl and your operating system works. I can only suggest familiarizing yourself with the programming concepts you're employing and with some testing strategy that allows you to eliminate the potential points one by one. For example, you could have easily ruled out fork-parallelism as a source of potential problems by reading up on fork() or by simply running your processes in a serial fashion.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://863851]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (17)
As of 2014-10-30 14:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (208 votes), past polls