Leaking Semaphores and Shared Memory

jcpunk has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks,

I am trying out IPC::Sharable and running into a bit of a misunderstanding on my part. I was wondering if anyone could point me in the right direction.

When I try to use references I leak semaphores all over the map....

#!/usr/bin/perl -w
use strict;
use IPC::Shareable;
use Data::Dumper;

my %stuff;
my $shm = tie %stuff, 'IPC::Shareable', undef, { destroy => 1 };
$SIG{INT} = sub { die "$$ dying\n" };
$SIG{CHLD} = sub { wait() };

my @children;
foreach (1..10)
 {
  my $pid = fork();
  if ($pid == 0)
   {
    push(@{$stuff{$_}}, $$);  # this leaks

#   $stuff{$_} = $$;          # this doesn't
    exit 0;
   }
  else { push (@children,$pid); }
 }

waitpid ($_,0) foreach (@children);

print Dumper(%stuff);
print "\n\nCLEAR YOUR SHARED MEMORY\n";
print "(ipcs -m ; ipcrm -m ; ipcs -s ; ipcrm -s)\n";
[download]

Apparently using this for refs is bad, but I really would love to make a hash of arrays for managing the result set of my actual code....

Can I get some assistance understanding what I seem to have missed? Perhaps a pointer or so in the right direction for this type of thing?

jcpunk

Comment on Leaking Semaphores and Shared Memory Download Code

Replies are listed 'Best First'.
Re: Leaking Semaphores and Shared Memory by gmargo (Hermit) on Nov 10, 2009 at 01:16 UTC
I think I've figured out what's going on. Corrections welcome. When the child process allocates a new array reference via the `push`, that reference is automatically tied which causes the creation of a new shared memory segment and a new shared semaphore. See the section on "REFERENCES" in IPC::Shareable. By default, the "destroy" flag for those is off, so when the child exits, those segments live on. When the parent exits gracefully, since it's "destroy" flag was on, all the shared memory and semaphores created by the parent are deleted. But that does not extend to the segments created by the children. Adding a call to `IPC::Shareable->clean_up_all()` at the end of the parent causes all of the segments and semaphores (of both the parent and children) to go away. You would have to add that to the signal handler too. Adding references to the tied structure is apparently very expensive, in terms of shared resources consumed. It would probably be best to find another way to do it.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Leaking Semaphores and Shared Memory
by gmargo (Hermit) on Nov 10, 2009 at 01:16 UTC

I think I've figured out what's going on. Corrections welcome.

When the child process allocates a new array reference via the push, that reference is automatically tied which causes the creation of a new shared memory segment and a new shared semaphore. See the section on "REFERENCES" in IPC::Shareable. By default, the "destroy" flag for those is off, so when the child exits, those segments live on.

When the parent exits gracefully, since it's "destroy" flag was on, all the shared memory and semaphores created by the parent are deleted. But that does not extend to the segments created by the children.

Adding a call to IPC::Shareable->clean_up_all() at the end of the parent causes all of the segments and semaphores (of both the parent and children) to go away. You would have to add that to the signal handler too.

Adding references to the tied structure is apparently very expensive, in terms of shared resources consumed. It would probably be best to find another way to do it.

[reply]
[d/l]
[select]