=head1 TITLE
Implementation of Threads in Perl
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 01 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 1
=head1 ABSTRACT
Perl 6 should be built around threads from the beginning.
=head1 DESCRIPTION
Perl 5 attempted (with relatively good success) to implement threads
atop the current architecture. It did, unfortunately, leave several
gaps, traps, and "features" in heavy concurrency uses. These
weaknesses could be fixed if Perl was built with threading from the
start.
All Perl programs are threaded. Most just only have one.
=head1 MOTIVATORS
Impatience, Hubris, and Laziness, in that order.
=head1 IMPLEMENTATION
Attempt to build-in thread constructs for the internals, while allowing
a Thread module to safely and robustly add user thread constructs, while
not making things bad for the single thread folks.
=head2 SUMMARY OF IMPLEMENTATION
=over 4
=item *
Create an additional pseudo-global stash, one per thread created, that is
local to that thread. This stash would be the default space for non-
lexical variables. C<$main::foo> == C<$foo> within one thread, while
C<$main::foo> != C<$main::foo> in different threads. There need be no way to
specify the particular thread-space, as it would be visible only to the
owning thread.
=item *
The Thread module should add a C<global> keyword or function that explicitly
access a variable in the program-global stash.
C<global $main::foo = $foo; # Let another thread know what my $foo is.>
C<global $main::foo = \$foo; # Share my local foo. Dangerous!>
C<$foo = global $main::foo; # Localize this instance of $main::foo.>
=item *
The Thread module should, on inclusion, also set the optree flag that triggers
mutex locking on variables within the perl core itself. (As differentiated
by a user-created and controlled mutex.) This is to guarantee that the
above constructs will actually work - user created race conditions aside.
=item *
Populate the thread-space stash with the built-ins, vice the program global
stash. Very few of the built-ins are meaningless in this threaded construct,
most are truly independent, and those that aren't, like $^O, should probably
be read-only anyway.
=back
=head2 IMPACT
=over 4
=item *
Impact on Perl on a non-thread-supporting architecture. None. (The mutex
locking code would be no-opped out, the Thread module would fail on inclusion,
preventing any of the global semantics from being invoked. The thread
space would appear to the program to be a standard global stash.)
=item *
Impact on Perl built for non-threaded use. None. Same as above.
=item *
Impact on a single-threaded program under a multi-threaded Perl. None,
for the above reasons. (There would be an additional flag check, vice,
I believe, automatic mutex locking under the current scheme.)
=item *
Impact on multi-threaded scripts under a multi-threaded Perl. Some. Mutex
locking would occur much as it does today. Current Perl scripts, without
the knowledge of global versus thread space would find data-sharing broken.
Threads have been declared experimental, and I believe the benefits of
simplifying threads in general outweigh the heartache of those (who would
benefit) that would have to change their programs.
=item *
Impact on Perl 5. Mutual compatibility between Perl 5 and Perl 6, with the
exception of C<use Thread> and the sematics it would add. (Obviously,
other changes to the language notwithstanding.)
=back
=head2 UNKNOWNS
=over 4
=item *
Mutex locking of a hash or array, and the scalars they contain, and vice
versa?
=item *
Mutex locking of a reference and the referree.
=item *
Limitations or assumptions on threading schemes other than those in pthreads,
due to the author's lack of experience with anything but.
=back
=head1 REFERENCES
None, currently.
