[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why is perl-5.6 unthreaded?



On Sat, Nov 25, 2000 at 12:38:21AM -0500, Matthew Sachs wrote:
>Is there a reason that perl-5.6 isn't threaded?  I know that there's
>perl-5.6-thread, but why a separate package?  [...]

Because thread support in perl is experimental.  From Configure:

   "Note that threading is a highly experimental feature, and
    some known race conditions still remain.  If you choose to try
    it, be very sure to not actually deploy it for production
    purposes.  README.threads has more details, and is required
    reading if you enable threads."

Being experimental, it also has other issues:

  * Backward compatibility for binary modules compiled with a previous
    version of perl is not possible for thread-enabled interpreters.

    Not breaking scores of programs which depend on binary modules when
    perl is upgraded is a very important consideration.

  * There are two incompatible threading options available with 5.6,
    5.005 threads and ithreads.

    Note that the perl-5.6-thread package implements the ithread model,
    which at this time doesn't provide user-level threads (ie. you
    can't "use Thread") as I understand it.

>either Debian users will have to modify that bit, or you need to have an
>option in the config file to specify an alternate perl binary to use.  Or
>a kludge like:
[ugh]

Config provides a value to use for #! (startperl) which should really be
used in scripts.  It is common to make self-extracting scripts with
interpolate that value.

>What about #! in general?  Why #!/usr/bin/perl and not #!perl?
>/usr/local/bin is a common place for perl, [..]

Because #! requires a full path.  (Although there *are* ways around
this, such as "#!/usr/bin/env perl" or the $if_running_under_some_shell
hack).

Regards,
-- 
Brendan O'Dea                                        bod@compusol.com.au
Compusol Pty. Limited                  (NSW, Australia)  +61 2 9810 3633



Reply to: