1. The most recent documentation for threads.pm states that variables are by default thread local? I have also read that everything gets copied over to a new thread. Which is it?

   Both!

   All lexical (my) variables are local to the thread they are declared in. Unless they are:

   • Explicitly shared by marking them with the :shared attribute at declaration time.

     This is the normal and best way of sharing data.

   • Explicitly shared using threads::shared::share() or threads::shared::shared_clone() functions.

     This can be useful, but is over used.

   • Implicitly cloned by being made closures. That is, declared in one thread, and referenced within another thread subroutine.

     A necessary part of threading in a language that supports closures.

   • Implicitly cloned because they exist in the spawning thread prior to a 'child' thread being spawned.

     I have no idea why this happens. In my opinion it should not. The good news is that is is easy to avoid.

   The simple rule is declare your thread subs and spawn them before declaring and populating any data or code you don't need them to have access to.

2. I am reading that sharing data between threads is slow. Is this true?

   Explicitly Shared data is relatively expensive to access -- less so for read-only than read-write.

   This is a necessary part of using threading with complex data types -- even Perl's scalar type is a complex data type capable of being a string, an integer, a floating point number, or a reference to anything. Perl has to protect its internals with locking.

   However, if you were using threads and shared data in any other language, you would incur much the same costs in order to ensure the internal integrity of your complex data types. The good news is that with Perl, this is taken care of for you.

3. One of the main purposes for my application will be to share data between worker threads.

   Perl is perfectly adept at sharing data. And very good at doing so simply -- from the application programmer's perspective -- and safely, whilst preventing the whole class of mysterious, hard to track down bugs that arise through accidental sharing and/or user implemented locking (or lack thereof). But that simplicity and safety has its costs.

   Whether those costs are a barrier to your application depends very much on how much and what access patterns are required for that shared data.

If you would describe your application, the shared data and usage patterns, we may be able to offer tips on the best way to program it.