Well, that is how (real) threading works. The problem is that Perl was not designed to support threading and trying to bolt threading on to the side of Perl has been attempted for years and nothing particularly good has been produced. The prior attempts at supporting threading in Perl were way too buggy and were eventually abandoned. The latest Perl threading tries to avoid the bugs (and is less buggy but is still buggy enough in my experience that avoiding it is usually wise) by having each thread duplicate the entire Perl interpretter. This gives us a sort of "worst of both worlds" situation (no operating system protections like we have with real fork, yet even more copying, memory use, and slowness than real fork). So I don't really consider it "threading" (more like a rather bizarre specialized use of threads, not a general-purpose threading implementation) nor an appropriate tool for the vast majority of cases.

If you had real threads, then what you describe would be completely natural. With Perl's current threading model, even shared data structures aren't simply shared (so someone said) so I doubt it would work well to try to share a large data structure using the current Perl threads.

Another approach for something like this is to use shared memory. Both Unix and Win32 support very nice shared memory facilities. However, Perl nearly refuses to deal with memory other than what its chosen malloc() hands to it, so getting Perl to use shared memory is quite difficult and once you get it to use it, you still end up serializing between the shared memory (that Perl won't work with directly) and Perl scalars. So, again, it likely isn't an appropriate solution for your problem.