I suppose that depends on how many more years you're willing not to contribute somehow to getting a good multi-threading model in Perl.

The first step in achieving a good threading model is understanding the limitations of the existing one.

And the first few steps in doing that is realising that:

1. the pthreads api has its own set of limitations and is far too low-level to use as the basis for threading in a HLL.
2. fork is a piss poor model for threading.
3. Copy On Write (COW) has little or no benefit when the C-level data structures representing Perl-level read-only variables are themselves routinely, internally mutated.
4. for threading to be fully effective in a high level language, you need both kernel-space (pre-emptive) threading and user-space (cooperative) threading.
5. Software Transaction Memory (STM) only works for undoable (re-startable) operations.

   If STM is the only state-sharing mechanism, then a very high proportion of the situations and algorithms that most benefit from threading can no longer be coded!

   • You can't undo changes to the file-system, so copy, move, rename, delete etc.

     Whilst it is conceivable to wrap these FS primitives such that they might be undone if the STM requires rollback, other processes may have noticed and acted upon the changes

   • You might attempt buffering reads and writes to files internally, until the STM commits?
   • What do you do for pipe and socket operations?

   STM promises an efficient solution to shared-state memory operations which can benefit some classes of algorithm (the kinds of things PDL does for instance), but it holds little promise for a huge range of other threading scenarios.

Did you ever visit one of those Echo Canyons, yell, and wonder if anyone is listening?

Did you ever stick your head into a lion's cage to try and pursuade it to become a vegetarian?