| … | |
… | |
| 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 |
