NAME
threads::variables::reap - reap variables in new threads
SYNOPSIS
use threads::variables::reap;
my $bigObj = SomeBigObj->new(); # create some real big object
reap($bigObj); # force $bigObj being reaped in each other thread
# created after this line is passedDESCRIPTION
This module provides a helper to ensure threads can/must have own instances of some variables. It ensures that all variables marked to get reaped are undef in a new thread (instead being a clone like default behaviour).
MOTIVATION
I became inspired to create threads::variables::reap when I was trying to switch a logging framework in a multi-threaded application, which logged to a database table, to Log::Log4perl. I read often, DBI wasn't made for threaded environments and here I was going to learn what it means in real life. So I found myseld in the situation, Joshua described for me: I have an object which can't persist into other threads or children. Reap it when that happen.
Another reason was to read about optimization effort in large applications, when they're going to be splitted in several threads. In those cases, all unnecessary objects for worker threads (or attributes of some objects which doesn't need to be available in other threads) could be marked with :reap and so new threads start with a small memory overhead.
EXPORT
This module exports only one function: reap.
SUBROUTINES/METHODS
reap(\[$@%])
Marks a given variable to get reaped in each other thread except the current. This could either help saving memory or increase safety when using modules which are known being not thread-safe.
Be careful about the calling convention of this function: it's taking the reference of the variable you'll give to it. So using reap(\@myarray) will abort with compilation errors and is not intended to work. Use reapref in those cases.
reapref
Marks the variable to get reaped in each new thread where the reference points to. This function isn't exported by default and shouldn't be used unless you're familiar with references and how cloning for new threads work.
AUTHOR
Jens Rehsack, <rehsack at cpan.org>
BUGS
Please report any bugs or feature requests to bug-threads-variables-reap at rt.cpan.org, or through the web interface at http://rt.cpan.org/NoAuth/ReportBug.html?Queue=threads-variables-reap. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.
LIMITATIONS
I wonder if variables could be marked as shared (using threads::shared) and for reaping seamless. This makes it impossible to give parameter objects for threads attributes that will be reaped for new threads, especially when used in common with Thread::Queue.
SUPPORT
You can find documentation for this module with the perldoc command.
perldoc threads::variables::reapYou can also look for information at:
RT: CPAN's request tracker
http://rt.cpan.org/NoAuth/Bugs.html?Dist=threads-variables-reap
AnnoCPAN: Annotated CPAN documentation
CPAN Ratings
Search CPAN
ACKNOWLEDGEMENTS
Larry Wall for giving us Perl - all our modules provide on his work. David Golden for his great contribution about Perl and threads on PerlMonks (see http://www.perlmonks.org/?node_id=483162). Steffen Mueller for Attribute::Handlers and the helpful explanantion there. Andrew Main, Adam Kennedy and Joshua ben Jore helping me pointing my problem I'm going to solve with this module.
LICENSE AND COPYRIGHT
Copyright 2010 Jens Rehsack.
This program is free software; you can redistribute it and/or modify it under the terms of either: the GNU General Public License as published by the Free Software Foundation; or the Artistic License.
See http://dev.perl.org/licenses/ for more information.