Ok, just because you rarely encounter problems that require multiple workers working on the same data, doesn't mean the rest of us rarely encounter those problems. My main project at work would be greatly helped by threads that worked across Windows, Unix, and Linux. But I don't have them, so I've left it in non-threaded mode.

IPC::SharedCache works great when there's only a little bit of caching. I'm not sure it's great for handling multiple huge trees of objects, from a cursory glance at the CPAN doc.

Any large structure(s) of data where different subsections can be worked on independantly, but the results must be fed back to the main process would benefit from threads. One common area is XML processing - working on each tree in a different worker thread is often possible and even desirable, and then you'll want to amalgamate the results in a final structure so that you can save a new XML file, for example, which cannot easily be done by multiple forked processes due to the close-tags that need to line up properly.

If I understand you correctly, you're using threads instead of scatter/gather processing?

I don't really see where exactly the gain would be, is the programming simpler, or maybe the setup?

However, I find this statement to be really strange: Any large structure(s) of data where different subsections can be worked on independantly, but the results must be fed back to the main process would benefit from threads. This is perfect application for workers pool model, why do you believe threads fit here?

If there would be really large structure, something like gigabytes-worth-of-data, that need to be edited in place, and can be edited by multiple workers, that would be perfect application for threads.