Cannot resume dead coroutine

[hanekomu]

.sub 'MyCoro'
    .yield(1)
    .yield(2)
    .yield(3)
    .return(4)
.end

.sub 'main' :main
    $I0 = MyCoro()
    say $I0
    $I0 = MyCoro()
    say $I0
    $I0 = MyCoro()
    say $I0
    $I0 = MyCoro()
    say $I0
    $I0 = MyCoro()
    say $I0
    $I0 = MyCoro()
    say $I0
    $I0 = MyCoro()
    say $I0
.end

prints:

1
2
3
4
Cannot resume dead coroutine.
current instr.: 'main' pc 35 (coro.pir:11)

on parrot-2.5.0-devel on Mac OS X 10.5.8.

I think the subroutine should restart, since the user of the sub doesn't care whether it's a coroutine or not.

[mikehh]

just to confirm this

I extracted the example from the pir book - chapter 6:

# example from pir book - chapter 6
#
  .sub 'MyCoro'
    .yield(1)
    .yield(2)
    .yield(3)
    .return(4)
  .end

  .sub 'main' :main
    $I0 = MyCoro()    # 1
    $I0 = MyCoro()    # 2
    $I0 = MyCoro()    # 3
    $I0 = MyCoro()    # 4
    $I0 = MyCoro()    # 1
    $I0 = MyCoro()    # 2
    $I0 = MyCoro()    # 3
    $I0 = MyCoro()    # 4
    $I0 = MyCoro()    # 1
    $I0 = MyCoro()    # 2
    $I0 = MyCoro()    # 3
    $I0 = MyCoro()    # 4
  .end

I ran it against my latest parrot build - r47979 - Ubuntu 9.10 amd64 (g++ with --optimize)

mhb@mhb-desktop:~/parrot$ parrot -t test_coroutine.pir 
0010 set_args PC10
0012 set P0, PC7                                        P0=PMCNULL PC7=Coroutine=PMC(0x10cf3f0)
0015 invokecc P0                                        P0=Coroutine=PMC(0x10cf3f0)
0000 set_returns PC1 (1), 1
0003 yield
0017 get_results PC8 (1), I0                                        PC8=FixedIntegerArray=PMC(0x11140d0) I0=0
001a set_args PC10
001c set P1, PC7                                        P1=PMCNULL PC7=Coroutine=PMC(0x10cf3f0)
001f invokecc P1                                        P1=Coroutine=PMC(0x10cf3f0)
0004 set_returns PC1 (1), 2
0007 yield
0021 get_results PC8 (1), I0                                        PC8=FixedIntegerArray=PMC(0x11140d0) I0=1
0024 set_args PC10
0026 set P2, PC7                                        P2=PMCNULL PC7=Coroutine=PMC(0x10cf3f0)
0029 invokecc P2                                        P2=Coroutine=PMC(0x10cf3f0)
0008 set_returns PC1 (1), 3
000b yield
002b get_results PC8 (1), I0                                        PC8=FixedIntegerArray=PMC(0x11140d0) I0=2
002e set_args PC10
0030 set P3, PC7                                        P3=PMCNULL PC7=Coroutine=PMC(0x10cf3f0)
0033 invokecc P3                                        P3=Coroutine=PMC(0x10cf3f0)
000c set_returns PC1 (1), 4
000f returncc
0017 get_results PC8 (1), I0                                        PC8=FixedIntegerArray=PMC(0x11140d0) I0=3
001a set_args PC10
001c set P1, PC7                                        P1=Coroutine=PMC(0x10cf3f0) PC7=Coroutine=PMC(0x10cf3f0)
001f invokecc P1                                        P1=Coroutine=PMC(0x10cf3f0)
Cannot resume dead coroutine.
current instr.: 'main' pc 33 (test_coroutine.pir:12)
FileHandle objects (like stdout and stderr)are about to be closed, so clearing trace flags.

[allison]

Talked with NotFound about this on IRC. To summarize:

Any call to a coroutine will have to know if it is the initial call (where arguments are passed) or a subsequent call (where arguments are not passed). So, the best default behavior is to allow the coroutine to "die", rather than to implicitly "ressurect" it and start from the beginning. But, we do need a way to restart a dead coroutine (and possibly even to restart one that is currently active). The two best suggestions were a 'restart' method on the coroutine object, and an optional named argument 'restart'=>1 passed in with the other arguments to the coroutine. The method is simplest, and so could be implemented first. The optional named argument is a possible future refinement.

[pmichaud]

On Sun, Jul 18, 2010 at 03:29:00PM -0000, Parrot wrote:
> #1702: Cannot resume dead coroutine
> Comment(by allison):
> 
>  Talked with NotFound about this on IRC. To summarize:

FWIW, the way that PGE managed this issue was to clone
Coroutines prior to making the initial call, and never
invoke the original Coroutine directly.  Then it became
relatively easy to "restart a coroutine" from the beginning
by making a new clone of the original.

Pm

[pmichaud]

See also TT #1710, which likely has some strong correlation with the items mentioned here.

Pm