Elizabeth Mattijsen <[EMAIL PROTECTED]> 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. -- Nick Ing-Simmons http://www.ni-s.u-net.com/
