Skip Menu |

This queue is for tickets about the Coro CPAN distribution.

Report information
The Basics
Id: 33965
Status: rejected
Priority: 0/
Queue: Coro

People
Owner: Nobody in particular
Requestors: cpan [...] chmrr.net
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 4.4
Fixed in: (no value)



Subject: local causes odd behavior
Using 'local' in coroutines causes unexpected behavior (see attached). Even if it is not expected to work, a note in the documentation warning about it would be useful. Thanks! - Alex
Subject: local-test.pl
#!/usr/bin/perl use strict; use warnings; use Coro; my %thing = (); use vars qw/$thing/; print "Main, value is @{[$thing || 'undef']} at start\n"; my $main = $Coro::current; for my $n (1..4) { async { warn "$n (before) value is @{[$thing || 'undef']}, expected undef\n"; { local $thing = $n; for my $i (1..3) { print "$n ($i) Value is @{[$thing || 'undef']}, expected $n\n"; cede; } } warn "$n (after) value is @{[$thing || 'undef']}, expected undef\n"; $main->ready; } } print "Main, value is @{[$thing || 'undef']} after creating asyncs\n"; schedule; print "Main, value is @{[$thing || 'undef']} at end, expected undef\n";
local works exactly as documented by perl (its a dynamic binding). this has nothing to do with coro, as local behaves as expected with or without coro being used. please study the perl documentation, especially the part "You really probably want to be using "my" instead".
Subject: Re: [rt.cpan.org #33965] local causes odd behavior
Date: Fri, 21 Mar 2008 20:59:13 -0400
To: bug-Coro [...] rt.cpan.org
From: Alex Vandiver <alexmv [...] MIT.EDU>
On Fri, 2008-03-21 at 19:29 -0400, Marc_Lehmann via RT wrote: Show quoted text
> local works exactly as documented by perl (its a dynamic binding).
Did even run the test I attached? It does *not* work exactly as documented by perl, because perl only has one call stack at once. Coro allows multiple call stacks, and thus local's behavior is less well defined; "leaving a block" could be construed to incude cede'ing to other coroutines, which would imply that local'd values would be part of per-coroutine state, in addition to the call stack. Regardless, Coro allows blocks to be exited in an order other than the order in which they were entered, which can restore the wrong values from the stack. In the test I attached, the value of $thing at the end of the program is 3 -- but, given a different ordering of coroutines exiting the local'd block, it could be anything between undef and 3. This is extremely non-intuitive. Does this clarify the issue at all? - Alex -- Networking -- only one letter away from not working
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #33965] local causes odd behavior
Date: Tue, 25 Mar 2008 19:16:54 +0100
To: "alexmv [...] mit.edu via RT" <bug-Coro [...] rt.cpan.org>
From: Marc Lehmann <schmorp [...] schmorp.de>
On Fri, Mar 21, 2008 at 09:00:17PM -0400, "alexmv@mit.edu via RT" <bug-Coro@rt.cpan.org> wrote: Show quoted text
> Did even run the test I attached?
No, I only read it carefully, is running it necessary to understand your problem (that would imply that your comments about it were wrong...)? Show quoted text
> It does *not* work exactly as > documented by perl, because perl only has one call stack at once.
The number and existance of a call stack is irrelevant, as local is not defined in relation to any call stack, it simply creates a dynamic binding. The only stack involved is the one local uses, and there is only one, with coro, or without, and the behaviour is the same. Show quoted text
> Coro allows multiple call stacks, and thus local's behavior is less well > defined
local's behaviour is well-defined with or without Coro, and it works the same. The fact that you don't understand what local does (and likely confuse it with my) is of little relevance. Show quoted text
> "leaving a block" could be construed to incude cede'ing to > other coroutines
No, leaving a block means leaving a block. If you "incude" anything that is only in your mind, Coro neither does that, nor implies that, nor documents that, nor aims for that: Leaving a block simply means leaving a block, and nothing else. Show quoted text
> which would imply that local'd values would be part of > per-coroutine state, in addition to the call stack.
If you start with obviously wrong statements you can derive anything out of them, so thats true. If I were the emperor of china... Show quoted text
> Regardless, Coro allows blocks to be exited in an order other than the > order in which they were entered
Yes. Show quoted text
> which can restore the wrong values from the stack
No. It will always restore the correct value. local introduces a _dynamic_ binding, not a lexical one, as you assume. Please take a good book about perl, which will immediately teach you that local will _not_ create local variables as you assume, and that you need to use my for that. Coro doesn't change that, you are just more surprised by your lack of understanding. Use "my", that is creating local variables, and works as you expect. local does something completely different, and what you apparently want cannot be implemented with it, as it simply isn't creating any local variable or scoped binding of any kind. You really want my, and this is completely independent of Coro. Show quoted text
> In the test I attached, the value of $thing at the end > of the program is 3 -- but, given a different ordering of coroutines > exiting the local'd block, it could be anything between undef and 3. > This is extremely non-intuitive.
local is extreemly unintuitive, because beginner programmers usually think it has something to do with local variables, which it doesn't have. Show quoted text
> Does this clarify the issue at all?
Yes, of course, it was completely clear to me before, too: You confuse local with the notion of local variables, a typical programmers error. You go farther in confusing the implied stack local uses with any call stack (which is not the case, and never was, regardless of how many call stacks are available). This is fine (being a typical beginners mistake), but please fetch yourself a book that explains the semantics of local vs. my and use my until you understand what local does. And please stop abusing the bugtracker, I am certainly more open to discuss this privately and teach you about local when I do not have to care for the bugtracker. The bugtracker is not a place to ask programming questions. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / pcg@goof.com -=====/_/_//_/\_,_/ /_/\_\
Subject: Re: [rt.cpan.org #33965] local causes odd behavior
Date: Tue, 25 Mar 2008 16:01:42 -0400
To: bug-Coro [...] rt.cpan.org
From: Alex Vandiver <alexmv [...] MIT.EDU>
On Tue, 2008-03-25 at 14:18 -0400, Marc Lehmann via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=33965 > > > On Fri, Mar 21, 2008 at 09:00:17PM -0400, "alexmv@mit.edu via RT" > <bug-Coro@rt.cpan.org> wrote:
> > Did even run the test I attached?
> > No, I only read it carefully, is running it necessary to understand > your > problem (that would imply that your comments about it were wrong...)?
Yes. Go run the code. There are two errors in it; one is totally PEBKAC, the other is not. - Alex -- Networking -- only one letter away from not working
Alex's point seems reasonable. It seems like Coro should document explicitly that "cede" and friends need to be thought of just as normal function calls, not as flow-control operators like "break" or "return" or "goto", even though Coro attempts to create a coroutine *abstraction*.
On Thu Mar 27 13:30:48 2008, glasser wrote: Show quoted text
> Alex's point seems reasonable.
I do not know who yo are but alex needs to learn perl. Obviously, cede is a function call, and obviously, local's behaviour is exactly as documented. I asked kindly not to abuse rt.cpan.org for progrmaming questions but since you continue to abuse it I will just delete ticket. Again, this is NOT a bug of any kind, and discussion of meta-questions or understanding of what local vs. my does is not done here. This is a *bug* tracking system that should help fixing *bugs*. Stop abusing it, that only detracts working people like me from doing useful workk.