Agreed! Here are two other cases, and the second one is quite interesting:

Share the reference of an array, cause the same problem:

use threads;
use threads::shared;

use Data::Dumper;

use warnings;
use strict;


my $a = [1,2];
print Dumper($a);
share($a);
print Dumper($a);
[download]

This printed:

$VAR1 = [
          1,
          2
        ];
$VAR1 = [];
[download]

More interestingly ;-) share an element of an array, does not lose the content, but alter the content:

use threads;
use threads::shared;

use Data::Dumper;

use warnings;
use strict;


my $a = [1,2];
print Dumper($a);
share($a->[0]);
print Dumper($a);
[download]

This gives you:

$VAR1 = [
          1,
          2
        ];
$VAR1 = [
          '1',#look at this
          2
        ];
[download]

I agree. Well it could be a bug, but I don't think this case is even documented. It should at least be listed as a caveat. I'm going to poke into the source.

Update: I should note that it also does that to the referenced array if you share a reference.

Let me know what you find out please. I'll hold off raising a perlbug until I get a conlusion about whether it's a code problem or a docs problem.

I've stared at shared.xs/.c, and seen nothing that looked like would cause this. That said, the internals are still mostly a mystery too me and magic positively scares me :)

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

This is strong magic, much stronger than mine. Go ahead and perlbug it, I took a look, but didn't see anything jumping out at me either.

mhoward - at - hattmoward.org

Observe:

use threads;
use threads::shared qw(share);

my @foo :shared = (1,2,3); # same as: share( @foo ); @foo = (1,2,3)
my @bar = (1,2,3); share( @bar );
print "foo = @foo, tied foo = ".(tied @foo)."\n";
print "bar = @bar, tied bar = ".(tied @bar)."\n";
__END__
foo = 1 2 3, tied foo = threads::shared::tie=SCALAR(0x82b714)
bar = , tied bar = threads::shared::tie=SCALAR(0x80a270)
[download]

Shared arrays, as shared hashes, are implemented using tie(), as can be observed from the output of the tied() function.

And losing / hiding the original value of something, is a known side-effect of tie(), as far as I know.

So there's no easy solution, I'm afraid. Fixing tie() to keep the original value, may be in order, but may also break a lot of programs.

Fixing threads.pm and threads::shared to not use tie() would be best, but not something we're going to see in the 5.8 life cycle of Perl.

I think that's basically the dilemma.

Liz

C:\>perl
use strict;
use warnings;
use threads::shared;
my @a = 1..4;
print @a,$/;
share @a;
die @a;
__END__
1234
1234 at - line 7.

C:\>perl
use strict;
use warnings;
use threads::shared;
my %a = 1 .. 4;
print %a,$/;
share %a;
die %a;
__END__
1234
1234 at - line 7.

C:\>perl -V
Summary of my perl5 (revision 5 version 8 subversion 3) configuration:
  Platform:
    osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    usethreads=undef use5005threads=undef useithreads=define usemultip
+licity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D
+_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT  -DNO_HASH_SEED -DPERL_IMPLICI
+T_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX',
    optimize='-MD -Zi -DNDEBUG -O1',
    cppflags='-DWIN32'
    ccversion='', gccversion='', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64
+', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf  -l
+ibpath:"c:\Perl\lib\CORE"  -machine:x86'
    libpth=C:\PROGRA~1\MICROS~3\VC98\lib
    libs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
+  comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netap
+i32.lib uuid.lib wsock32.lib mpr.lib winmm.lib  version.lib odbc32.li
+b odbccp32.lib msvcrt.lib
    perllibs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool
+.lib  comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  n
+etapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib  version.lib odbc3
+2.lib odbccp32.lib msvcrt.lib
    libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
    gnulibc_version='undef'
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:
+ref,icf  -libpath:"c:\Perl\lib\CORE"  -machine:x86'


Characteristics of this binary (from libperl): 
  Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL
+_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
  Locally applied patches:
      ActivePerl Build 809
      22218 Remove the caveat about detached threads crashing on Windo
+ws
      22201 Avoid threads+win32 crash by freeing Perl interpreter slig
+htly later
      22169 Display 'out of memeory' errors using low-level I/O
      22159 Upgrade to Time::Hires 1.55
      22120 Make 'Configure -Dcf_by=...' work
      22051 Upgrade to Time::HiRes 1.54
      21540 Fix backward-compatibility issues in if.pm
  Built under MSWin32
  Compiled at Feb  3 2004 00:28:51
  @INC:
    c:/Perl/lib
    c:/Perl/site/lib
    .
[download]

If threads isn't loaded when threads::shared is, threads::shared::share becomes a no-op. =)

mhoward - at - hattmoward.org