>>>>> "SWM" == Steven W McDougall <[EMAIL PROTECTED]> writes:
PRL> All threads see the same compiled subroutines
>>
>> Why? Why not allow two different threads to have a different view of
>> the universe?
SWM> 1. That's how it works in compiled languages. You have one .exe, and
SWM> all threads run it.
Perl is not C. One of its strengths is its introspection.
SWM> 2. Thread programming is difficult to begin with. A language where
SWM> different threads see different code could be *very* difficult to
SWM> program in.
I'm thinking of threads as fork on steroids. Fork doesn't let you easily
share things. What we really should get is the isolation of fork, but
with the ease of sharing what is necessary.
And I don't know about you, but I don't see what is morally wrong with
having one thread using foo and getting 7 back and another using foo
and getting an -42.
PRL> All threads share the same global variables
>>
>> _All_ or only as requested by the user (ala :shared)?
SWM> All.
Dan has gone through this with perl5 and he really would rather not
have to go through that. He would like the amount of data that needs
protection reduced.
You are also creating problems when I don't want mediation. What if
I know better than perl and I want to us a single item to protect
a critical section?
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?
SWM> These are the ways in which one subroutine can get access to the
SWM> lexical variables of another in Perl5. RFC178 specifies that these
SWM> mechanisms work across threads.
References are a completely different animal than access. A data item
is independent of a thread. It is a chunk of memory. If a thread can
see it, then it is available.
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.
SWM> Data coherence just means that the interpreter won't crash or corrupt
SWM> its internal data representation. RFC178 uses the term *data
SWM> synchronization* for coordinating access to multiple variables between
SWM> threads.
Then this RFC seems to be confusing two things. This is for -internals
we don't even have any internal structures, so how can you be protecting
them. If you are working at the language level this is the wrong forum.
>> 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.
SWM> Sigh...if that's the best I can get, I'll take it.
I'm not the decisor here, I'm just pointing out another way to look
at the problem. I really don't think you want to have _all_ variable
actually visible. Even if they were, you will most likely have only
a limited number that you want visible.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
