I checked out Parrot from CVS on 2002Aug30 to an IRIX64 system.
shell01:/usr/tmp/swmcd/parrot>uname -a
IRIX64 shell01 6.5 07201611 IP27
make compiled OK.
make test failed all the t/pmc/perlhash.t tests.
Running
parrot t/pmc/perlhash_1.pbc
produced a bus error.
I chased the err
> SWM> If you actually compile a Perl program, like
>
> SWM> $a = $b
>
> SWM> and then look at the op tree, you won't find the symbol "$b", or "b"
> SWM> anywhere in it. The fetch() op does not have the name of the variable
> SWM> $b; rather, it holds a pointer to the value for $b.
>
> W
RFC 178 proposes a shared data model for Perl6 threads. In a shared
data model
- globals are shared unless localized
- file-scoped lexicals are shared unless the thread recompiles the
file
- block scoped lexicals may be shared by
- passing a reference to them
- closures
- declaring one s
> Example
>
> @a = ();
> async { push @a, (1, 2, 3) };
> push @a, (4, 5, 6);
> print @a;
>
> Possible output: 142536
Actually, I'm not sure I understand this.
Can someone show how to program push() on a stack machine?
- SWM
> > You aren't being clear here.
> >
> > fetch($a) fetch($a)
> > fetch($b) ...
> > add ...
> > store($a) store($a)
> >
> > Now all of the perl internals are done 'safely' but the result is garbage.
> >
> I think there may be a necessity for more than just a work area to be
> non-shared. There has been no meaningful discussion so far related to
> the fact that the vast majority of perl6 modules will *NOT* be threaded,
> but that people will want to use them in threaded programs. That is a
> non
> what if i do $i++ and overflow into the float (or bigint) domain? that
> is enough work that you would need to have a lock around the ++. so then
> all ++ would have implied locks and their baggage. i say no atomic ops
> in perl.
>From RFC 178
[Atomic] operations typically lock their opera
> DS> Some things we can guarantee to be atomic.
> This is going to be tricky. A list of atomic guarentees by perl will be
> needed.
>From RFC 178
...we have to decide which operations are [atomic]. As a starting
point, we can take all the operators documented in C and
all the functions docume
> DS> I'd definitely rather perl not do any sort of explicit user-level locking.
> DS> That's not our job, and there be dragons.
> Please explain how this is possible?
Just say no...to locks.
> Does this mean that without user specifying a lock, perl will allow
> a chaotic update pattern to b
I think we are talking about the same issues, but we can't seem to get
in sync on the terminology. I'm going to try to get off the
merry-go-round by recapitualting the two approaches.
RFC178
- globals are shared unless localized
- file-scoped lexicals are shared by all code in the file
- block-s
> Single thingee access mediation, should be done automatically by perl.
> The multi-thingee complex mediation should have the user step in, since
> solving it (correctly and efficiently) is a complex problem.
I'm not sure we have a common understanding of the terms we are using.
Can you give som
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 pr
> SWM> Question: Can the interpreter determine when a variable becomes
> SWM> shared?
> SWM> Answer: No. Then neglecting to put a :shared attribute on a shared
> SWM> variable will crash the interpreter. This doesn't seem very Perlish.
> Err, no. It won't crash the interpreter. It'll make the sc
> There is a fundemental issue on how values are passed between
> threads. Does the value leave one thread and enter the other or are
> they shared.
> The idea tossed around -internals was that a value that crosses a thread
> boundary would have a wrapper/proxy attached to handle the mediation.
> There is a fundemental issue on how values are passed between
> threads. Does the value leave one thread and enter the other or are
> they shared.
> The idea tossed around -internals was that a value that crosses a thread
> boundary would have a wrapper/proxy attached to handle the mediation.
> > I dropped the I<$thread>->C call from this interface, and didn't
> > say what happens if a thread Cs. There are several possibilities
> I think that the try stack should unwind all the way through the new Thread
> call -- that is, that the catches for the block that the thread was started
> i
> KF> #!/my/path/to/perl
> KF> sub foo_generator { my $a = shift; sub { print $a++ } }
> KF> my $foo = foo_generator(1);
> KF> $foo->();
> Thread-> new($foo);
> KF> Is $a shared between threads or not? If $a is not shared, we've broken
> KF> lexicals.
> Not unless it is so declar
> I'm not completely sure what you are trying to do with this RFC.
This RFC describes the programming interface to Perl6 threads.
It documents the function calls, operators, classes, methods, or
whatever else the language provides for programming with threads.
Perl5 has a thread interface, bu
> Steven W McDougall wrote:
> > > The more interesting case is this:
> > >
> > > #!/my/path/to/perl
> > > sub foo_generator { my $a = shift; sub { print $a++ } }
> > > my $foo = foo_generator(1);
> > > $foo->();
> >
> The more interesting case is this:
>
> #!/my/path/to/perl
> sub foo_generator { my $a = shift; sub { print $a++ } }
> my $foo = foo_generator(1);
> $foo->();
> Thread->new($foo);
> Is $a shared between threads or not?
$a is shared between threads.
The anonymous subroutine
> That a user my need to have two or more variables in sync for proper
> operation. And cooperative threads don't address that issue.
> Cooperative only helps _perhaps_ with perl not needing to protrect its
> own structures.
We are in agreement.
I was specifically addressing the problem of prot
> > We could either discuss alternate approaches for RFC1, or I could
> > submit a new RFC for a thread architecture that gives me the
> > performance I want.
> Both are more than welcome. (If you want alternate approaches or
> counter-arguments to be fully documented, then doing both in an RFC
> > as in the non-threaded case, or do we get
> >
> > $global::{foo} -> *global::foo -> &global::foo -> { print 1 }
> > $thread::{foo} -> *thread::foo -> &thread::foo -> { print 2 }
> Okay, I understand. Here's how I perceive it
>
> There is no global::foo, just two thread-specific
I don't understand the problem with these scenarios.
> A couple of other scenerios
>
> Thread 1Thread 2
> push(@a, @b); $a[35]++
>
What does
> User level cross variable consistancy.
mean?
>
> push(@a, $b);
> $acount++ if $b <35;
>
>
> E
>> Users can (and do) write open code in modules.
> I don't understand. Do you think that needs to be prevented?
No, I just want to know what happens when they do it.
Let's look at an example.
1. Non-threaded
#!/usr/local/bin/perl
sub foo { print 1 }
foo();
eval 'sub foo { pr
RFC1v3 says
5. Threads are a runtime construct only. Lexical scoping and
compile issues are independent of any thread boundaries. The
initial interpretation is done by a single thread. use Threads may
set up the thread constructs, but threads will not be spawned
until runtime.
Do separate threads
- all see the same file-scoped lexicals
- each get their own file-scoped lexicals
#!/usr/local/bin/perl
use Threads;
my $a = 0;
my $t1 = Thread->new(\&inc_a);
my $t2 = Thread->new(\&inc_a);
$t1->join;
$t2->join;
print "$a";
sub inc_a
{
$a++;
}
What should the outp
> The problem is, as long as expressions can be within each other,
> and include terms that are multiple expressions, a robust deadlock
> avoidance strategy is required even with cooperative threading.
In order to understand this, we need to think in more detail about how
the Perl interpreter wor
> Writing a threads package correctly is a non-trivial thing to do.
We don't have to write a threads package.
We just have to thread the interpreter.
There's a difference.
> Perl doesn't currently run on a system that doesn't have a reasonably good
> threading library.
I abandoned an NT -> M
> A new regular expression metacharacter \m would match any of the
> following characters: ([{"'< in a regexp. A later \M metacharacter
> would match the corresponding closing pair character )]{"'>
> I within the string being searched.
^
LanguageReco
Are Perl6 threads preemptive or cooperative?
Last week, I asked whether Perl6 threads support SMP. There were a
handful of responses, mostly to the effect that
- we don't know
- we don't care
- we get whatever the native thread library gives us
This assumes that Perl6 uses the native thread lib
1. Scalars
Thread1 Thread2
$a = 1; $a = 2;
$a is set to 1 and then 2, or 2 and then 1. It just depends which
thread gets there first.
2. Arrays
Thread1 Thread2
push @a, (1, 2, 3); push @a, (4, 5, 6);
The interesting question
I've spent the last 3 years programming WindowsNT threads in MSVC++,
and I *really* like it. I want similar capabilities in Perl6.
1 The C++ thread model
Here is the thread model that I have in C++. It is a starting
point for thinking about what I want in Perl.
Every thread sees
- the same code
Does Perl6 support Symmetric MultiProcessing (SMP)?
This is a *huge* issue. It affects everything else that we do with
threads.
1 No
If Perl6 doesn't support SMP, then the interpreter can be implemented
with cooperative threads. It calls yield() internally to switch
threads, and by design, it o
34 matches
Mail list logo
