in reply to Perl forking and shared memory strangeness under Windows

When you fork in AS perl under win32 (I think cygwin builds work differently), you aren't creating another process, You are instantiating another interpreter on a new thread. That's the tie-in to iThreads.

The "Free to wrong pool" indicates that a piece of memory allocated by one instance of the interpreter has come up for destruction by a different interpreter.

Quite how this is alleviated by the presence of a commented out line that references no variables I can't imagine, but as a fix, you might try requireing Win32::MMF::Shareable within each branch of the if( fork ) { statement.

I'm hazarding a guess that some load-time (BEGIN|INIT|CHECK} code is allocating a variable in the parent thread and the child thread is inheriting it and trying to free it.

This is mostly guesswork, but it would be worth a try.

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Timing (and a little luck) are everything!

Replies are listed 'Best First'.
Re: Re: Perl forking and shared memory strangeness under Windows
by Roger (Parson) on Feb 23, 2004 at 06:54 UTC
    Thanks for the suggestion BrowserUk, I have reviewed the module code for Win32::MMF::Shareable, and after extensive debugging, I (think that I) have discoverred that the module might not be thread safe. I am doing some experiments at the moment to see if I could have independend sets of data both child and parents so they don't interfere with each other, as currently the child and parent share the same set of global data.

    I tried your suggestion: I removed the use Win32::MMF::Shareable line at the start, which gets loaded at compile time, and then added require in each parent and child processes after the fork. The problem some how has gone away. The following is the test code I used:
    #!C:/Perl/bin/perl -w
use strict;
use Data::Dumper;

if( fork )
{
  require Win32::MMF::Shareable;
  my $ns = tie( my %share, 'Win32::MMF::Shareable', 'share' ) || die;
  sleep(1);
  $share{parent} = 1;
  print Dumper(\%share);
}
else
{
  require Win32::MMF::Shareable;
  my $ns = tie( my %share, 'Win32::MMF::Shareable', 'share' ) || die;
  $share{child} = 1;
}

    [download]

    Is this because the require is executed at run-time, which causes two different copy of Storable to be loaded at run-time, which in turn gets freed properly in their own instances?

    And thanks again!

[reply]
[d/l]
      Is this because the require is executed at run-time, which causes two different copy of Storable to be loaded at run-time, which in turn gets freed properly in their own instances?

      Yes. YW :)

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      Timing (and a little luck) are everything!
[reply]

In Section Seekers of Perl Wisdom