multiple perl versions

Daniel J. Luke dluke at geeklair.net
Tue Feb 14 13:19:11 PST 2012


On Feb 14, 2012, at 4:03 PM, Ryan Schmidt wrote:
> On Feb 14, 2012, at 13:41, Daniel J. Luke wrote:
>> +1 from me. It would probably also be a good idea to make it perl5.14 +threads (and if a non-threaded perl is needed, it should probably be a separate port) at the same time.
> 
> Yes, what's the deal with threads?

from perldoc threads:

"Since Perl 5.8, thread programming has been available using a model
 called interpreter threads which provides a new Perl interpreter for
 each thread, and, by default, results in no data or state information
 being shared between threads."

> I don't know what it implies. Who are the users who need perl without threads,

someone experiencing a bug with perl built with ithread support (I guess), or someone who has benchmarked the two and found perl with thread support to be slower than perl built without it (I would guess that the differences are minimal for any useful perl script, but I haven't benchmarked this myself).

... basically no one. As a data point, the system perl shipped by Apple is built with threads.

> who are the users who need perl with threads,

anyone doing perl programming that wants to use ithreads or anyone using a perl script that makes use of ithreads.

> and who are those who don't care?

near 100% of perl users, I would wager.

> If we can possibly eliminate the threads variant and make threads support either always on or always off that will surely simplify our life.


I agree, threads always on makes sense to me.

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+





More information about the macports-dev mailing list