As promised on P5P, this is the first version of my proof of concept
implementation for shared variables using a seperate thread.
Have fun and let me know if it helps you.
Liz
=======================================================================
The uploaded file
Thread-Tie-0.01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/E/EL/ELIZABETH/Thread-Tie-0.01.tar.gz
size: 8736 bytes
md5: 22e61ca07a1d1de851d0aa500e007bc2
=head1 NAME
Thread::Tie - tie variables into a thread of their own
=head1 SYNOPSIS
use Thread::Tie;
# use default thread + tieing + create thread when needed
tie $scalar, 'Thread::Tie';
tie @array, 'Thread::Tie';
tie %hash, 'Thread::Tie';
# create a thread beforehand
my $thread = Thread::Tie::Thread->new;
tie $scalar, 'Thread::Tie', {thread => $thread};
# use alternate implementation
tie $scalar, 'Thread::Tie',
{ thread => $thread, module => 'Own::Tie::Implementation' };
# initialize right away
tie $scalar, 'Thread::Tie', {}, 10;
tie @array, 'Thread::Tie', {}, qw(a b c);
tie %hash, 'Thread::Tie', {}, (a => 'A', b => 'B', c => 'C');
=head1 DESCRIPTION
The standard shared variable scheme used by Perl, is based on tie-ing the
variable to some very special dark magic. This dark magic ensures that
shared variables, which are copied just as any other variable when a thread
is started, update values in all of the threads where they exist as soon as
the value of a shared variable is changed.
Needless to say, this could use some improvement.
The Thread::Tie module is a proof-of-concept implementation of another
approach to shared variables. Instead of having shared variables exist
in all the threads from which they are accessible, shared variable exist
as "normal", unshared variables in a seperate thread. Only a tied object
exists in each thread from which the shared variable is accesible.
Through the use of a client-server model, any thread can fetch and/or update
variables living in that thread. This client-server functionality is hidden
under the hood of tie(). So you could say that one dark magic (the current
shared variables implementation) is replaced by another dark magic.
I see the following advantages to this approach:
=over 2
=item memory usage
Shared variables in this approach are truly shared. The value of a variable
only exists once in memory. This implementation also circumvents the memory
leak that currently (threads::shared version 0.90) plagues any shared array
or shared hash access.
=item tieing shared variables
Because the current implementation uses tie-ing, you can B<not> tie a shared
variable. The same applies for this implementation you might say. However,
it B<is> possible to specify a non-standard tie implementation for use
B<within> the thread. So with this implementation you B<can> C<tie()> a
shared variable. So you B<could> tie a shared hash to a DBM file à la
dbmopen() with this module.
=back
Of course there are disadvantages to this approach:
=over 2
=item pure perl implementation
This module is currently a pure perl implementation. This is ok for a proof
of concept, but may need re-implementation in pure XS or in Inline::C for
production use.
=item tradeoff between cpu and memory
This implementation currently uses (much) more cpu than the standard shared
variables implementation. Whether this would still be true when re-implemented
in XS or Inline::C, remains to be seen.
=back
