I'm not so great in my first language:) I understand what you write and that's enough--for me.

In purely causal terms, the error message Attempt to free unreferenced scalar: SV xxxxxxxx during global destruction. simply means that when your perl script is ceaning up memory when exiting, a reference was encountered that needed to be freed. Before the memory containing the reference can be freed, the reference count of the thing it pointed at has to be decremented, but when the reference count of the referent is check, it is already at 0. Hence the warning is issued.

What this indicates is that somehow, a reference to an object has been created without the reference count of the referent having been incremented. This probably constitutes a bug. However, as the problem can been alleviated by not creating objects that are implicitly shared between threads--something that isn't useful and you aren't meant to do--the severity of the bug is fairly minor.

It may also be that it isn't possible to correct the "bug", because it is a symptom of trying to do something that cannot be done--but that is supposition.

The bug arises during the duplication process invoked when you spawn a thread having previously created an object, This can be demonstrated by modifying your original snippet to create more than one thread:

#! perl -slw
use strict;
use threads;
use IO::String;
## Point A

my $var;
my $io = IO::String->new($var);
## Point B

my @th= map{ threads->new(\&Update); } 1..5;

$_->join() for @th;

sub Update{};
__END__
P:\test>368516
Attempt to free unreferenced scalar: SV 0x1aba0c4 during global destru
+ction.
Attempt to free unreferenced scalar: SV 0x1a4e06c during global destru
+ction.
Attempt to free unreferenced scalar: SV 0x19e1fdc during global destru
+ction.
Attempt to free unreferenced scalar: SV 0x19749fc during global destru
+ction.
Attempt to free unreferenced scalar: SV 0x2b26134 during global destru
+ction.
[download]

As you can see, you now get one warning message for each thread created. This suggests, though I'm not exactly clear on the mechanisms involved, that during the replication process, each thread is getting it's own copy of the reference to a single SV somewhere, but the reference count of that SV is not being incremented. Then at exit, when perl is trying to clean up those references, the first thread's reference (of the 6--five I created + the original), to the commmon SV gets cleaned up and the SV reference count gets decremented to 0. All is hunky dory and no error is issued.

However, when the references in the other threads come to be cleaned up, the attempt is made to decrement the reference count of the common SV and it is found to already be 0. Hence the warnings.

The fact that this only happens when the program is exiting means that you could probably ignore the messages if the rest of the program was working as expected. But in the long term, it is a sure indication that something is wrong, and if you tried to actually make use of the implicitly shared object, then you will almost certainly not get the behaviour you are expecting.

With respect to further reading on threads. The last time I looked I couldn't actually find much in the way of good documentation on iThreads. There is a little general description stuff around but not much by way of practical "How to"s or Cookbook style.

This isn't really surprising. As far as I am aware, the implementation mechanisms involved in iThreads are completely unique to Perl. They evolved to compensate for the problems encountered in trying to implement pThreads for perl. The underlying nature of Perl itself, and the non-reentrancy of perl's internal data structures and the C-runtime that underlay it, mean that even sharing Perl's scalars between concurrent threads of execution, never mind arrays, hashes and others, is nearly impossible to do safely.

As such, iThreads are very new and until very recently, not stable. Consequently, not many people have done very much with them, and so there is no great pool of knowledge from which to draw in order to write such documentation.

Personally, I believe that iThreads are now stable enough that they are usable in production environments. And we will slowly see them being utilised for real work, despite their inherent limitations, and the body of knowledge required to construct a cookbook will evolve.