… | |
… | |
72 | }, $class; |
72 | }, $class; |
73 | } |
73 | } |
74 | |
74 | |
75 | =item $prev->transfer($next) |
75 | =item $prev->transfer($next) |
76 | |
76 | |
77 | Save the state of the current subroutine in $prev and switch to the |
77 | Save the state of the current subroutine in C<$prev> and switch to the |
78 | coroutine saved in $next. |
78 | coroutine saved in C<$next>. |
|
|
79 | |
|
|
80 | The "state" of a subroutine only ever includes scope, i.e. lexical |
|
|
81 | variables and the current execution state. It does not save/restore any |
|
|
82 | global variables such as C<$_> or C<$@> or any other special or non |
|
|
83 | special variables. So remember that every function call that might call |
|
|
84 | C<transfer> (such as C<Coro::Channel::put>) might clobber any global |
|
|
85 | and/or special variables. Yes, this is by design ;) You cna always create |
|
|
86 | your own process abstraction model that saves these variables. |
|
|
87 | |
|
|
88 | The easiest way to do this is to create your own scheduling primitive like this: |
|
|
89 | |
|
|
90 | sub schedule { |
|
|
91 | local ($_, $@, ...); |
|
|
92 | $old->transfer($new); |
|
|
93 | } |
79 | |
94 | |
80 | =cut |
95 | =cut |
81 | |
96 | |
82 | # I call the _transfer function from a perl function |
97 | # I call the _transfer function from a perl function |
83 | # because that way perl saves all important things on |
98 | # because that way perl saves all important things on |
84 | # the stack. |
99 | # the stack. Actually, I'd do it from within XS, but |
|
|
100 | # I couldn't get it to work. |
85 | sub transfer { |
101 | sub transfer { |
86 | _transfer($_[0], $_[1]); |
102 | _transfer($_[0], $_[1]); |
87 | } |
103 | } |
88 | |
104 | |
89 | =item $error, $error_msg, $error_coro |
105 | =item $error, $error_msg, $error_coro |