> $thread = new Thread \&func , @args;
> $thread = new Thread sub { ... }, @args;
>async { ... };
> $result = join $thread;
>
> critical { ... }; # one thread at a time in this block
>
> =item C BLOCK
>
> Executes BLOCK in a separate thread. Syntactically, C BLOCK
> works
>
> use Thread;
>
> $thread = new Thread \&func , @args;
> $thread = new Thread sub { ... }, @args;
>async { ... };
> $result = join $thread;
>
> $thread = this Thread;
> @threads = all Thread;
>
> $thread1 == $thread2 and ...
> yield();
>
> critical { ... };
> 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->();
> > > Thread->new($foo);
> >
> > > Is $a shared between threads o
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Thread Programming Model
=head1 VERSION
Maintainer: Steven McDougall <[EMAIL PROTECTED]>
Date: 31 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 185
Status: Developing
=head1 ABSTR
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> It just kinda irks me here:
TC> $total += 2 * do {
TC> my $count = 0;
TC> for $n (@nums) { $count += $n }
TC> $count;
TC> };
TC> I rather that were:
TC> $total += 2 * do {
TC> my $count = 0;
Tom Christiansen writes:
> >Yes, but 'eval' has the semantics "run this code but don't let it play
> >any funny tricks on me, like dying or anything", where 'do {...} while'
> >has the semantics "a while loop that evaluates its condition at the
> >end". There's no obvious reason why 'return'
[cc'd to internals to check a possible performance problem.]
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->();
> > Thread->new($f
>Tom Christiansen writes:
> > >However, I really don't want to see 'return' become a kind of 'last'
> > >for do{}. How would I return from a subroutine from within a do loop?
> >
> > You already can't do that (as it were) from within an eval.
>Yes, but 'eval' has the semantics "run this code bu
>AFAICT we could make it a syntax error iff foo is not used in void context;
>Perl must be able to tell whether or not it is used in order to know what
>context the result is in, right?
Well, that depends. Often you must delay till run-time. When Perl
simply sees something like:
sub fn {
Tom Christiansen writes:
> >However, I really don't want to see 'return' become a kind of 'last'
> >for do{}. How would I return from a subroutine from within a do loop?
>
> You already can't do that (as it were) from within an eval.
Yes, but 'eval' has the semantics "run this code but don'
At 02:30 PM 8/31/00 -0500, Christopher J. Madsen wrote:
>Peter Scott writes:
> > I dunno, maybe a last in a do block whose value is used by
> > something should be a syntax error. We're talking about code like
> >
> > $x += do { $y = get_num; last if $y == 99; $y } while defined $y;
> >
> 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
Peter Scott writes:
> I dunno, maybe a last in a do block whose value is used by
> something should be a syntax error. We're talking about code like
>
> $x += do { $y = get_num; last if $y == 99; $y } while defined $y;
>
> right? *Shudder*
Yes, but we're also talking about code like
>However, I really don't want to see 'return' become a kind of 'last'
>for do{}. How would I return from a subroutine from within a do loop?
You already can't do that (as it were) from within an eval.
But I while I am not completely bothered by letting the value
dangle here:
($msg, $defs
At 11:21 AM 8/31/00 -0600, Tom Christiansen wrote:
> >I want last, next, etc. to magically work where I want them to:
I too want last to work in do loops.
> > do {
> >last if /booger/;
> >...
> > } while ( ... );
>
>Special cased for postfix modifiers, or generalized? If so,
>what's t
On Thu, Aug 31, 2000 at 02:13:23PM -0500, Christopher J. Madsen wrote:
> Jonathan Scott Duff writes:
> >do { ... last; ... }; # exit the block immediately
> >do { ... next; ... }; # equivalent to last?
> >do { ... redo; ... }; #
Jonathan Scott Duff writes:
> On Thu, Aug 31, 2000 at 01:26:26PM -0500, Christopher J. Madsen wrote:
> > I too would like to see last, next, & redo work with do loops.
>
> *Only* do loops or do blocks in general? And what should they do?
Well, I suppose that for consistency's sake they shou
Perl6 RFC Librarian wrote:
> =head2 Each thread gets its own copy of block-scoped lexicals upon
> execution of C
>
> Example 8
>
> #!/my/path/to/perl
> foo();
> Thread->new(\&foo);
>
> sub foo
> {
> my $a = 1;
> print $a++;
> }
[prints "11"]
This must b
On Thu, Aug 31, 2000 at 01:26:26PM -0500, Christopher J. Madsen wrote:
> I too would like to see last, next, & redo work with do loops.
*Only* do loops or do blocks in general? And what should they do?
do { ... last; ... }; # exit the block immediately
do { ... next; .
Tom Christiansen writes:
> >>One could argue that do{} should take return so it might have a value,
> >>but this will definitely annoy the C programmers.
>
> >So what.
>
> So what is that it *already* annoys us, which is *why* we would like to
> last out of a do. Perhaps you should be a
>>One could argue that do{} should take return so it might have a value,
>>but this will definitely annoy the C programmers.
>So what.
So what is that it *already* annoys us, which is *why* we would like to
last out of a do. Perhaps you should be able to last out if a retval
isn't wanted (as i
On Thu, 31 Aug 2000 11:21:26 -0600, Tom Christiansen wrote:
>One could argue that do{} should take return so it might have a value,
>but this will definitely annoy the C programmers.
So what.
"Annoying" would be to have a situation that is *less* powerful in Perl
than in C, not *more*.
Oh, and
>I want last, next, etc. to magically work where I want them to:
> do {
>last if /booger/;
>...
> } while ( ... );
Special cased for postfix modifiers, or generalized? If so,
what's the return value?
$x = TERM OP do { BLOCK } OP TERM;
Actually, these are all pretty similar in
I want last, next, etc. to magically work where I want them to:
do {
last if /booger/;
...
} while ( ... );
Nat
Chaim Frenkel wrote:
>
> This is making the index variable into an a wrapper object.
No it isn't. Or at least it doesn't have to.
Often there is a need to find the key an object was found in a container.
More often in hashes than in arrays.
And I think this discussion belongs in -data.
At 11:38 AM 8/31/00 +0200, Bart Lateur wrote:
>The articial distinction between
>
> do BLOCK while condition;
>
>and
>
> EXPR while condition;
>
>should go, because the former is nothing but a subcase of the latter.
>Currently, the former executes the do BLOCK at least once, while
Likely this should be an RFC. I'm too lazy to write it in that format
right now, but I want to send this thing out before it slips my mind
again. Somebody else may pick it up, if he or she wants it. If not, I'll
eventually may have to do it myself.
The articial distinction between
do BLO
27 matches
Mail list logo
