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

Hi monks!

I've got a little problem with IPC::Shareable that I don't really understand, first of all, some code:
#!/opt/perl/bin/perl -w use IPC::Shareable; my %options = ( create => 1, exclusive => 0, mode => 0644, destroy => 0 ); tie %data, 'IPC::Shareable', 'data', { %options }; my $i = 0; while (1) { print $i++."\n"; %data = (); $data{'test'}{'test'} = $i; sleep 1; }

In the while-loop I want to delete %data, which also works fine as it should, but the $data{'test'}{'test'} = $i line always creates a new semaphore in the IPC-Memory, but data is pretty much the same as before. But when I would do $data{'test'} = $i it wouldn't.I know that IPC always creates new shares for each hash-var but I clear them all so it shouldn't be doing this or am I wrong? And how to prevent this?

I've got a loop that checks a file each 20 seconds and if it changes it updates a hash with new data so my IPC-Mem would come to its limits pretty fast.

giant

Edit kudra, 2002-10-27 Changed title

Replies are listed 'Best First'.
Re: IPC::Shareable
by valdez (Monsignor) on Oct 24, 2002 at 10:15 UTC

    I'm not sure, but it seems to me that the man page of IPC::Shareable describes your problem:

    REFERENCES
    When a reference to a non-tied scalar, hash, or array is assigned to a tie()d variable, IPC::Shareable will attempt to tie() the thingy being referenced. This allows dis­parate processes to see changes to not only the top-level variable, but also changes to nested data. This feature is intended to be transparent to the application, but there are some caveats to be aware of.

    First of all, IPC::Shareable does not (yet) guarantee that the ids shared memory seg­ments allocated automagically are unique. The more automagical tie()ing that happens, the greater the chance of a collision.

    Secondly, since a new shared memory segment is created for each thingy being referenced, the liberal use of references could cause the system to approach its limit for the total number of shared memory segments allowed.

    Hth, Valerio

    update: after running your example I need to clean my shm... :)

      Yea I did read that, too but why doesn't it delete the old ones that aren't needed any more? doesn't make sense to me...

      giant
Re: IPC::Shareable -> Workarround
by kodo (Hermit) on Oct 24, 2002 at 13:55 UTC
    It works when I call the clean_up method manually. This is not perfect, but seems to work, here's the code:
    #!/opt/perl/bin/perl -w use IPC::Shareable; my %options = ( create => 1, exclusive => 0, mode => 0644, destroy => 0 ); tie %data, 'IPC::Shareable', 'data', { %options }; my $i = 0; while (1) { print $i++."\n"; %data = (); IPC::Shareable->clean_up(); tie %data, 'IPC::Shareable', 'data', { %options }; $data{test}{'test'} = $i; sleep 1; }


    giant
      Slightly less duplicated code and processing, also strict compliant:
      #!/usr/bin/perl -w use strict; use IPC::Shareable; my $options = { create => 1, exclusive => 0, mode => 0644, destroy => 0 }; my $i = 1; while (1) { print "$i\n"; tie my %data, 'IPC::Shareable', 'data', $options; $data{test}{test} = $i++; sleep 1; %data = (); IPC::Shareable->clean_up(); }

      Makeshifts last the longest.

UPDATE!
by kodo (Hermit) on Oct 24, 2002 at 13:07 UTC
    Interesting is that when I change the while-loop to:
    while (1) { print $i++."\n"; $data{'test'}{'test'} = $i; sleep 1; }

    it works fine. So it only creates new ones when I empty %data before I put data in there...
    I think that's a bit logical but how do I tell it to not create a new one...or I'll set a flag in each hash-element to use it in the scripts or not....

    giant

      If I understood correctly there is no way to tell IPC::Shareable to not create a new one; on the other hand if you undef something that has something tied inside it, the module will not untie recursively all references contained...

      Ciao, Valerio