Re^4: why won't the hash go away?

Memory management via fork is a good idea; I've used it in several situations (usually when I'm going to leak memory).

The problem WoodyWeaver may have is that when the child exits normally, it will still go through the ten hours of data structure destruction, and the parent will wait the whole time. Taking some code from davidrw and some from my own node,

use Set::Light;

my $pid = fork;
die "Can't fork: $!" if ! defined $pid;
if($pid){  # parent
    my $start_time = time;
    wait;
    printf "Child exited after %d seconds\n", time - $start_time;
}
else {     # child
    my $start_time = time;

    my $set = Set::Light->new();
    for( my $i = 0; $i < 10_000_000; $i++ ) {
        $set->insert( $i );
    }

    printf "Child done after %d seconds\n", time - $start_time;
    exit;
}
__END__
Child done after 36 seconds
Child exited after 163 seconds
[download]

The solution to this is not to let the child exit normally (i.e., kill it). In the above code, if I change "exit" to "kill 9 => $$", the OS does the memory reclamation, and the output looks like this:

Child done after 32 seconds
Child exited after 32 seconds
[download]

Comment on Re^4: why won't the hash go away? Select or Download Code

Replies are listed 'Best First'.
Re^5: why won't the hash go away? by WoodyWeaver (Monk) on Jan 14, 2008 at 22:21 UTC
I haven't seen the problem you describe, oddly enough. That might be OS / version specific. My routines in the past would exit because of time or state limits exceeded (I'd have them start over after four hours or four billion states examined) or signals (I'd have them print and die if I sent them an INT or HUP). They would exit quickly and normally on the latter (some flavor of linux and ActiveState, 5.8.something.) I did take the excellent advice presented here. My code now "uses memory management via fork". Read more... (1182 Bytes) A run shows the following: `Mon Jan 14 12:36:28 2008 Launched process to play cards. user 0.031 system 0.031 children 0, 0 Mon Jan 14 16:29:34 2008 Child process finished. user 9774.546 system 556.765 children 0, 0 Mon Jan 14 16:29:35 2008 Launched process to play cards. user 9774.546 system 556.781 children 0, 0` [download] The "Child process finished" is after the waitpid, so that should mean that my kid is dead. There is a caveat on times() that says "times for children are included only after they terminate" which should have occurred. Why didn't I see any value on the line for 16:29:34 (and similarly for 16:29:35). Is this some sort of race condition? Or is my OS (oh, look at the Vista out this window!) so brain dead that the feature isn't implemented?	[reply] [d/l] [select]
Re^6: why won't the hash go away? by BrowserUk (Patriarch) on Jan 14, 2008 at 22:31 UTC
If you are using fork on Vista, you aren't forking and there are no child processes involved. Which might explain why you can't get your misunderstanding to align with the documentation. See this (skip down to the section labelled "How Perl does it" if your in a hurry) to understand what's "brain dead". Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^7: why won't the hash go away? by WoodyWeaver (Monk) on Jan 14, 2008 at 23:23 UTC
Thanks, BrowserUK, cool article. I did have ProcessExplorer running, and saw that it was a new thread and not a new process instance. So it sounds like third and fourth arguments of times() are going to stay zero. Looking at memory utilization, I can see that the system is starting to get a bit pokey, but the good news is that the working set is only about two thirds of the peak working set, so it seems my objective was successful. So its not "memory management by forking" but "memory management by plucking threads". A richer image, I think.	[reply]