develooper Front page | perl.perl5.porters | Postings from March 2001

The State of Perl Threads???

From:
Marc M. Adkins
Date:
March 18, 2001 15:09
Subject:
The State of Perl Threads???
Message ID:
OIECKMOJOMBCOBBGDMKAEEDKCDAA.Marc.M.Adkins@Doorways.org
I've been looking for some information on the state of threads in Perl.
Having spent some hours perusing mailing list archives and Perl-related
sites on the web I'm going to attempt to answer my own question.  I'm
posting it on a few mailing lists at the very real risk of demonstrating my
ignorance.  Hopefully someone who really _knows_ will provide an indignant
response correcting my errors...

THERE BE TWO

First off, there are currently two different kinds of thread support in
Perl:  the Thread package and ithreads.  These are vastly different thread
support mechanisms.  The former is currently in disfavor and under some sort
of revision.

* Thread.pm

The Thread package provides a Thread object with various fairly normal
methods.  Threads are similar to and also slightly different from whatever
threading model you're used to.  Functions are started in their own threads.
Variables and function calls can be synchronized via semaphores.
Thread-safe queues are provided.  Manipulation of threads from Perl source
code is directly supported.  This is probably (at least in a naive way) what
you really want.

Current releases of Perl (e.g. ActivePerl build 623) document this module
but warn that it is due for (possibly massive) revision.  None of the binary
distributions come with this support enabled.  If you attempt to

	use Thread;

in your code you will get a message like:

	No threads in this perl at ...

This may be considered the "old" thread model.

* iThreads

Interpreter threads, or ithreads, are an entire different mechanism.  With
an ithread, the entire Perl interpreter (or at least the process stack and
global variables that make a specific instantiation unique) are duplicated.

This is similar to the fork()/join() mechanism supported by Unix.  In fact,
using these threads it is possible to provide behavior similar to Unix from
Windows.  This is a _big_ deal (at least to some of us) as now a bunch of
legacy Perl code from Unix will work under Windows.

On the flip side, there is no way to manipulate ithreads directly from Perl
other than fork()/join().  In addition, there are some serious performance
considerations (mostly memory usage) on the Windows platform.

Most importantly, these threads aren't so much threads as pseudo-processes.
On Windows they are _implemented_ as threads, but they don't provide shared
variable space or any of the other usual aspects of using threads.  They
function just the same as Unix processes spawned with fork(), so they may be
threads but they don't provide thread behavior to the programmer.

Current binary distributions come with this support enabled.

This may be considered the "other" thread model.

VERSION SUPPORT

* 5.005

This is the version that provided the Thread.pm module.  It was experimental
at that time.  Not all of the modules (even the core modules included in the
Perl distribution) were fixed to be thread-safe.  It was definitely a case
of caveat programmer.

* 5.6.0

This is the version that provided ithreads.  They are intended to provide
fork()/join() to Windows-based Perl.  There are some hints that this may be
incompatible with the 5.005 Thread package.

* 5.6.1

This looks like a maintenance release.  The trial version currently being
distributed doesn't include any more or different thread support.  It is
still sent out with 5.005 thread support disabled.

* 5.7.0

I downloaded a copy of the 5.7.0 development tree.  Nothing leaped out at me
from looking at what's in this.  I can't tell if any "new" threads will be
in this release or not.

* 6.0

As I understand it, Perl v6 (Topaz?) will be a vastly different Perl.  Larry
Wall has opened the direction of the language to other parties more than
previous versions, and I saw mention of 300+ specific language comments.

As I understand it, the shape of Perl v6 is currently being hammered out.
If Topaz is the codename for Perl v6 then it is only now beginning to run
programs.  I'm guessing that v6 won't be out before 2002/2003, so it isn't
really on _my_ radar yet.

BUILDING FOR THREADS

So, if you want the threads that are there, what do you do?  Well, get the
source and build it for yourself!  The following switches seem to apply:

* Thread.pm

The following switches should control the old thread model:

	usethreads
	use5005threads

I'm not sure why there would be two.  Perhaps there is a later version of
threads (post-5.005) that works differently.  I must admit, I haven't
attempted to turn this on yet.

* iThreads

The following switches should control the iThread model:

	useithreads
	usemultiplicity

I read a message discussing these two.  Apparently usemultiplicity causes
Perl to be built so that multiple interpreters can be run in separate
threads (interpreter data is separated properly for this).  However, without
useithreads, the ithreads can't be actually started.  Or something like
that.

Of course, these are currently turned on for the binaries I've been
downloading, so you probably don't have to worry about it.

CONCLUSION

Currently, there is really _no_ thread support in Perl.  The use of ithreads
to dummy up fork()/join() under Windows is inaccessible directly and in
practice it is really a method of providing multiple _processes_, not
multiple threads.  This is most obvious when you consider the lack of shared
variable space.  If you want threads as such, this isn't what you want.

The older thread model is in disfavor and will change sometime into a "new"
thread model.  So you can build Perl with this turned on, but it won't do
you a lot of good (since the packages aren't thread-safe) and anything you
write will eventually break.

Regarding a third or "new" thread model:  I don't know what it will look
like or when it will be available.  I assume that there is a _lot_ of work
to be done to truly support this, and that may in fact push it off to v6.
Darn it.

The future of threads in Perl is "cloudy" to those of us not in the
development loop.  I would suspect that a group of Perl porters are working
on it, but for what version?  And what will it look like?

Well, like I said earlier, all I can do is show my ignorance...


    ***************************************************
    * Marc M. Adkins             * Software Mercenary *
    * Marc.M.Adkins@Doorways.org * Dilettante * Human *
    ***************************************************




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About