Jens Rehsack

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 passed

DESCRIPTION

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::reap

You can also look for information at:

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.