On Wed, 2002-10-30 at 14:52, Perrin Harkins wrote:
> harm wrote:
> 
> >On Wed, Oct 30, 2002 at 06:05:51PM +0800, Philippe M. Chiasson wrote:
> >  
> >
> >>For the same reason that running this:
> >>$> perl -e'fork; { $foo = {}; print "$$:$foo\n"}'
> >>1984:HASH(0x804c00c)
> >>1987:HASH(0x804c00c)
> >>
> >>produces this for me, every single time I run this program
> >>
> >>You are assuming that if (0x804c00c) is equal in different processes,
> >>they must be pointers(or references, or handles) to the same thing. And
> >>it is not the case ;-)
> >>
> 
> Wait, ins't it the case?  That number is supposed to be the location in 
> memory.  It seems like these are all pointing to the same hash.  I can't 
> explain how that would happen though, based on the code shown here.

You're confusing virtual memory with physical memory. Given an SMP
system where pid 1984 and 1987 can both actually run at the same time
(thus ensuring neither is "swapped out") address 0x804c00c actually
occupies two completely distinct blocks of physical memory.

$ perl -e '$foo = {}; fork; print "$$:$foo\n";'
18161:HASH(0x80fd254)
18162:HASH(0x80fd254)
$ perl -e 'fork; $foo = {}; print "$$:$foo\n";'
18163:HASH(0x80fd254)
18164:HASH(0x80fd254)

The effects are entirely expected. Perl takes up so much memory, and
that amount doesn't increase or decrease unless I recompile perl. So the
first allocation for a hash seems bound to occur at the same address in
virtual-memory every single time.

$ perl -e '$foo = {bar => 1};fork;print "$$:$foo" . $foo->{bar} . "\n";'

That works like you'd expect, doesn't it? Now consider this:

#!/usr/bin/perl
$foo = {};
if (fork == 0) {
        sleep(1);
} else {
        $foo->{bar} = 1;
}
print "$$:$foo:" . $foo->{bar} . "\n";'

All this serves to demonstrate is that the parent cannot modify the
child's memory map. While both exist in the same place in virtual
memory, the values obviously contain different values, and the physical
memory itself is different.

It's difficult to fully appreciate this in Perl... Maybe someone will
make a proper mmap() someday.


Reply via email to