in reply to Why use threads over processes, or why use processes over threads?
Threading ostensibly has two main advantages over forking.
This is because a thread should consist of little more than a scheduler object containing a set of registers, a stack segment and some scheduler administration state. Unlike a process, there should be no need to copy large amounts of memory, as threads should be able to re-use the existing process' copy of memory.
It's the very fact that memory is shared between the threads, that make this possible.
The problem with perl's implementation of threads is that the non-reentrancy of perl's code segments, combined with the lack of a suitable engrained model for semaphores and synchronisation. The result is the only way to approach a 'safe' and cross-platform implementation of threads in perl is to emulate forking. Performing this emulation throws away both advantages that threading had to start with.
Despite heroic efforts on behalf of the developers, the underlying, rather old-fashioned, non reentrant nature of perl's core requires that everything, code and data segments be copied. This completely wipes out both advantages. First, the copying is done in user mode rather than kernel mode, throwing away all the years of optimisations and testing that now exists in kernels that support forking natively. Having copied everything, each thread now has it's own copy of every piece of memory, throwing away the benefits of COW on those platforms that support it, and requiring hookey and clumsy a bit-at-a-time, duplication and serialisation of all shared data, effectively throwing away the second advantage of threads -- direct, fast access to shared memory.
The result is, that perl threading implementation as is, is at best utilitarian, and at worst, broken. This is unsurmountable given the nature of perl's core as is, and would only be fixable with a complete re-write of the perl core. The problem runs very deep. Even the POSIX C-runtime that underlies so much of the perl core is inherently non-reentrant, and without reentrancy built-in from the lowest levels, making effective use of threads, where these are natively fast and efficient, simply isn't possible.
Personally, I am pinning my hopes on Perl 6 (and maybe Ponie) to bring the true benefits of threading to perl, but I have my fears that the predominately unix-guru based nature of the development teams, and indeed, the whole development processes, mean that even these will likely concentrate on the strengths of unix-based models and modes of operation, and that will prevent the kernel from being tuned (or tunable) for models and modes of operation that originate outside of the unix platform.
Sadly, I don't see the cross-platform support at the deepest levels of perl development improving to the point where those of us that use perl on non-unix or unix-clone platforms will ever truly gain access to the kernel strengths of our platforms. The nature of 'other' platforms isn't that they are worse or inferior to unix, nor that they are better or superior to unix, they are simply different. They tackle the same set of problems and choose different solutions. It might be possible to come up with a perl 'model' of the OS, that is flexible enough to encompass all underlying platforms in a transparent(ish) manner if sufficient effort where expended to do so, but while the development process continues to be "Do what works on unix and then try and force fit that mechanism onto non-unix platforms.", the lot of those who choose or have to use non-unix platforms will always be one of playing catch-up on builds, reliance upon 3rd-parties, and a mismatch between what we know is possible and what we can actually do.
|
|---|