Agreed. I recently spent a lot of time exploring ways of trying to untilise threads more effectively (under Win32), and discovered the nature and scale of the problem. It hasn't put me off of the benefits of threads over processes in my environment, nor in the wider context where they are a natural part of the system. It has, however, put me off of trying to utilise them to any great extent from perl.

They still have their utility under Win32, as the absence of a native fork, means that there is little or nothing to choose between forking and threading, but using threads does expose a little (very little) more control of the multi-processing facilities than the fork emulation.

I wish I could be more enthusiastic, but the deep rooted nature of perl's non-reentrancy, as you noted, make it near impossible to improve the situation, give the current implementation of perl.

From what I have understood of the Parrot architecture, the objectification of the fundemental types, should mean that it would (will?) be possible to cheaply and transparently serialise access to individual scalars. Embedding a semaphore within every scalar, and using it for every write operation may sound horrendous, but applied at the core level, it shouldn't be that problematic or costly. However, if it is not done at the core level, trying to retroactively add it would be disasterous.

Time will tell, but I won't be holding my breath.