|XP is just a number|
what the history behind perl not having "real" threadsby perl-diddler (Hermit)
|on Feb 25, 2013 at 07:36 UTC||Need Help??|
perl-diddler has asked for the
wisdom of the Perl Monks concerning the following question:
First I need to define what I mean... because people might point at ithreads and say it has thread support.
But I refer to the manpage 'perl' that describes perl5 (when it was new) as having "lightweight" threads.
Lightweight, means they are less than a separate process (to some level). At the very least, though, it would mean that they are NOT completely separate copies of the perl-interpreter which is what we have in the current implementation (perlthtut):
In Perl interpreter threads, each 'thread' runs in is own Perl interpreter and any data sharing between threads must be explicit.More clearly it is stated that:
Perl Threads are Not X Threads for all values of X.
It sounds like there was an earlier version of threads in 5.005, that is referred to as having problems... was it that version that tried to use 'lightweight' threads?
Was the problem found that it was too hard too make the core interpreter thread safe? Or was it in something else?
I think about this only because sometimes I look at code and think about how this or that could be run in parallel, but if it is in a separate process -- that the overhead of setup and going into a separate process would negate any benefits of various low-level optimizations.
Sure, there are many applications where the overhead of creating separate processes is far outweighed by the work done in each process -- so that doesn't mean the concept is worthless or fatally flawed, just that the "bar" for them to be useful is higher -- especially combined with the inability to share anonymous data between them.
I mean, if you write object oriented code and want a class to provide an object for you, how are you going to specify that object such that it can be shared without jumping through hoops and restrictions?
Maybe it's a trade off between perl's flexibility and power (and ability for data to be interchangeably made program and vice-versa) that creates extra pitfalls in this area?
Just wondering if anyone knew the history of this area?