What I'm trying to do in RFC178 is take the thread model that you get
in compiled languages like C and C++, and combine it with the Perl5
programming model in a way that makes sense.
There may be reasons not to follow RFC178 in Perl6. Maybe
- it's too hard to implement
- there are performance problems
- Perl6 can actually do more for the user
- it just doesn't make sense for Perl6
But RFC178 is the thread model that I'd like to program in, and I'm
spec'ing it in the hopes that I'll actually get it in Perl6.
> PRL> All threads see the same compiled subroutines
>
> Why? Why not allow two different threads to have a different view of
> the universe?
1. That's how it works in compiled languages. You have one .exe, and
all threads run it.
2. Thread programming is difficult to begin with. A language where
different threads see different code could be *very* difficult to
program in.
> PRL> All threads share the same global variables
>
> _All_ or only as requested by the user (ala :shared)?
All.
> PRL> Each thread gets its own copy of block-scoped lexicals upon execution
> PRL> of C<my>
>
> Why? Perhaps I want a shared my?
Different invocations of a subroutine within the same thread get their
own lexicals. It seems a natural extension to say that different
invocations of a subroutine in different threads also get their own
lexicals.
> PRL> Threads can share block-scoped lexicals by passing a reference to a
> PRL> lexical into a thread, by declaring one subroutine within the scope of
> PRL> another, or with closures.
>
> Sounds complex to me. Why not make it simply visible by marking it as such?
These are the ways in which one subroutine can get access to the
lexical variables of another in Perl5. RFC178 specifies that these
mechanisms work across threads.
> PRL> The interpreter guarantees data coherence
>
> It can't, don't even try. What if I need two or more variables kept in
> sync. The user has to mediate. Perl can't determine this.
Data coherence just means that the interpreter won't crash or corrupt
its internal data representation. RFC178 uses the term *data
synchronization* for coordinating access to multiple variables between
threads.
> Perhaps, I'm archaic, but I really wouldn't mind if the thread model
> basically copied the fork() model and required those variable that have
> to live across threads to be marked as :shared.
Sigh...if that's the best I can get, I'll take it.
- SWM
