...
#use Win32::MMF::Shareable;
use ScalarTieTest;

print "Process starting...\n";

#my $ns = tie my $wait, 'Win32::MMF::Shareable', 'wait' or die;
my $ns = tie my $wait, 'ScalarTieTest', 'wait' or die;
...
[download]

package ScalarTieTest;
use Carp;
use strict;

sub TIESCALAR {
 my $class = shift;
 my $scalar = shift;
 carp "ScalarTieTest::TIESCALAR($scalar)";
 return bless \$scalar, $class;
}

sub FETCH {
 my $self = shift;
 confess "wrong type" unless ref $self;
 croak "usage error" if @_;
 carp "ScalarTieTest::FETCH()";
 return $$self;
}

sub STORE {
 my $self = shift;
 confess "wrong type" unless ref $self;
 my $new_scalar = shift;
 croak "usage error" if @_;
 carp "ScalarTieTest::STORE($new_scalar)";

 $$self=$new_scalar;
 return $new_scalar;
}

1;
[download]

Hi ant9000, thanks for trying out the code. I tried your ScalarTieTest module with the Tk test script, and I get the exact same behaviour as my Shareable module. Something smells fishy here... Perhaps this problem is Windows specific, may be the kill 'HUP', $pid didn't work as expected on Windows platform?

I think you hit the right spot! This is from perlport man page:

 "kill()" doesn't have the semantics of "raise()",
 i.e. it doesn't send a signal to the identified
 process like it does on Unix platforms.  Instead
 "kill($sig, $pid)" terminates the process identi­
 fied by $pid, and makes it exit immediately with
 exit status $sig.  As in Unix, if $sig is 0 and
 the specified process exists, it returns true
 without actually terminating it. (Win32)

I can't tell you where to go from now, but at least you've found out what the problem is - and made me learn something, too :-)

Hi ant9000, I have modified the test program, this time I have confirmed that there is a 'bug?' inside Tk's waitVariable method.

The main script


use strict;
use Tk;
use Win32::MMF::Shareable;

print "Process starting...\n";

my $ns = tie my $wait, 'Win32::MMF::Shareable', 'wait' or die;
$wait = 0;

my $mw = MainWindow->new;
$mw->Button( -text => '$wait',                   -command => sub { pri
+nt "\$wait is $wait\n" } )->pack;
$mw->Button( -text => 'waitVariable( \\$wait )', -command => \&start )
+->pack;
$mw->Button( -text => 'local $wait++',           -command => \&stop  )
+->pack;
$mw->Button( -text => 'remote $wait++',          -command => sub{ syst
+em "tkremote.pl" } )->pack;

MainLoop;

sub start
{
  print "waiting for \$wait (was $wait)\n";
  $mw->waitVariable( \$wait );
  print "finished waiting for \$wait (is now $wait)\n";
}

sub stop
{
  print "\$wait++ by pid $$\n";
  $wait++;
}
[download]


And the child script -


use strict;
use Tk;
use Win32::MMF::Shareable;

tie my $wait, 'Win32::MMF::Shareable', 'wait' or die;
print "Remote process $$ increment \$wait...\n";
$wait++;
[download]


And I have added debug message to the FETCH method in Shareable.pm. The following is the results I got:



Process starting...                 # 3008 is pid of main

3008 FETCHING...                    # pressed waitVariable
waiting for $wait (was 0)

$wait++ by pid 3008                 # pressed local++
3008 FETCHING...
3008 FETCHING...
3008 FETCHING...
finished waiting for $wait (is now 1)

3008 FETCHING...
waiting for $wait (was 1)
Remote process 3808 increment $wait...  # pressed remote++
3808 FETCHING...             # remote process incremented $wait

3008 FETCHING...             # pressed 'wait'
$wait is 2
[download]


As you can see here, eventhough the remote process incremented the $wait variable, the Tk's waitVariable method skipped the FETCH of the tied variable.

Any ideas?

You could try to add a debug line to STORE, too: that way, following the process should be easier; in any case, it seems that STORE gets called correctly by tkremote.pl, but that the tie interface is not notified when $wait changes.
Well, I cannot solve your problem, but I might offer you a bunch of CPAN suggestions for a workaround:
• Tie::Watch, implementing "watches" or callbacks over Perl variables (could be the module Tk is using under the hood, dunno)
• Tie::Coupler, to couple scalars together (maybe this module "senses" changes better than Tk?)
• Tie::RemoteVar, a mechanism for sharing variables that should be both easy to use and more portable than the one you're using.
I have not actually tried any of those, but they seem a promising starting point.

Hi JamesNC, thanks for the info, I am now certain the problem can not be easily solved. I will try the perl.tk newsgroup when I get back home tonight.