Front page | perl.ithreads |
Postings from August 2002
From: Nick Ing-Simmons
August 11, 2002 04:13
Message ID: email@example.com
Elizabeth Mattijsen <firstname.lastname@example.org> writes:
>As promised on P5P, this is the first version of my proof of concept
>implementation for shared variables using a seperate thread.
>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.
That is actually exactly what threads::shared is supposed to do as well.
The only difference being that the "separate thread" has a shadowy
existance and the client threads assume its identity (briefly) to become
their own server - which was supposed to be an optimization :-(
>=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.
As the threads::shared scheme is _supposed_ to be exactly as you describe
there _should_ be no difference here.
>=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.
This is still an advantage of your scheme - as the server-thread is
"visible" its variable can be tied using normal approaches.