First off, as far as forking is concerned, you're right: by doing the set-up work in the parent, it gets copied into the kids in shared copy-on-write memory. Thus, there is a huge runtime boon to doing that - both in memory and CPU.

That said, threads are another beast. As BrowserUk points out, these are perl threads, which make them a slightly different beast than regular win32- or p- threads.

They're different enough that I don't bother using them. However, I look forward to perl 6 partly for the hopes that by putting threading into the base language, we might get some good, lightweight threads where the types of workarounds that BrowserUk mentioned in his OP are no longer necessary. Of course, what fixing threads does to PONIE in threaded situations ... well, I don't know.

I really wish I had a thread-safe perl where I could just do stuff in parallel and not have to worry about inter-thread communication. I have some very parallelisable tasks in my code which could really gain from this, especially when it's running on multi-CPU machines (usually 4-way machines). Unfortunately, I'm using blessed references all over the place, and the overhead probably would kill me.