… | |
… | |
186 | |
186 | |
187 | async { |
187 | async { |
188 | Coro::terminate "return value 1", "return value 2"; |
188 | Coro::terminate "return value 1", "return value 2"; |
189 | }; |
189 | }; |
190 | |
190 | |
191 | And yet another way is to "->cancel" (or "->safe_cancel") the coro |
191 | Yet another way is to "->cancel" (or "->safe_cancel") the coro |
192 | thread from another thread: |
192 | thread from another thread: |
193 | |
193 | |
194 | my $coro = async { |
194 | my $coro = async { |
195 | exit 1; |
195 | exit 1; |
196 | }; |
196 | }; |
… | |
… | |
209 | So, cancelling a thread that runs in an XS event loop might not be |
209 | So, cancelling a thread that runs in an XS event loop might not be |
210 | the best idea, but any other combination that deals with perl only |
210 | the best idea, but any other combination that deals with perl only |
211 | (cancelling when a thread is in a "tie" method or an "AUTOLOAD" for |
211 | (cancelling when a thread is in a "tie" method or an "AUTOLOAD" for |
212 | example) is safe. |
212 | example) is safe. |
213 | |
213 | |
214 | Lastly, a coro thread object that isn't referenced is "->cancel"'ed |
214 | Last not least, a coro thread object that isn't referenced is |
215 | automatically - just like other objects in Perl. This is not such a |
215 | "->cancel"'ed automatically - just like other objects in Perl. This |
216 | common case, however - a running thread is referencedy b |
216 | is not such a common case, however - a running thread is referencedy |
217 | $Coro::current, a thread ready to run is referenced by the ready |
217 | by $Coro::current, a thread ready to run is referenced by the ready |
218 | queue, a thread waiting on a lock or semaphore is referenced by |
218 | queue, a thread waiting on a lock or semaphore is referenced by |
219 | being in some wait list and so on. But a thread that isn't in any of |
219 | being in some wait list and so on. But a thread that isn't in any of |
220 | those queues gets cancelled: |
220 | those queues gets cancelled: |
221 | |
221 | |
222 | async { |
222 | async { |
223 | schedule; # cede to other coros, don't go into the ready queue |
223 | schedule; # cede to other coros, don't go into the ready queue |
224 | }; |
224 | }; |
225 | |
225 | |
226 | cede; |
226 | cede; |
227 | # now the async above is destroyed, as it is not referenced by anything. |
227 | # now the async above is destroyed, as it is not referenced by anything. |
|
|
228 | |
|
|
229 | A slightly embellished example might make it clearer: |
|
|
230 | |
|
|
231 | async { |
|
|
232 | my $guard = Guard::guard { print "destroyed\n" }; |
|
|
233 | schedule while 1; |
|
|
234 | }; |
|
|
235 | |
|
|
236 | cede; |
|
|
237 | |
|
|
238 | Superficially one might not expect any output - since the "async" |
|
|
239 | implements an endless loop, the $guard will not be cleaned up. |
|
|
240 | However, since the thread object returned by "async" is not stored |
|
|
241 | anywhere, the thread is initially referenced because it is in the |
|
|
242 | ready queue, when it runs it is referenced by $Coro::current, but |
|
|
243 | when it calls "schedule", it gets "cancel"ed causing the guard |
|
|
244 | object to be destroyed (see the next section), and printing it's |
|
|
245 | message. |
|
|
246 | |
|
|
247 | If this seems a bit drastic, remember that this only happens when |
|
|
248 | nothing references the thread anymore, which means there is no way |
|
|
249 | to further execute it, ever. The only options at this point are |
|
|
250 | leaking the thread, or cleaning it up, which brings us to... |
228 | |
251 | |
229 | 5. Cleanup |
252 | 5. Cleanup |
230 | Threads will allocate various resources. Most but not all will be |
253 | Threads will allocate various resources. Most but not all will be |
231 | returned when a thread terminates, during clean-up. |
254 | returned when a thread terminates, during clean-up. |
232 | |
255 | |
… | |
… | |
250 | |
273 | |
251 | my $sem = new Coro::Semaphore; |
274 | my $sem = new Coro::Semaphore; |
252 | |
275 | |
253 | async { |
276 | async { |
254 | my $lock_guard = $sem->guard; |
277 | my $lock_guard = $sem->guard; |
255 | # if we reutrn, or die or get cancelled, here, |
278 | # if we return, or die or get cancelled, here, |
256 | # then the semaphore will be "up"ed. |
279 | # then the semaphore will be "up"ed. |
257 | }; |
280 | }; |
258 | |
281 | |
259 | The "Guard::guard" function comes in handy for any custom cleanup |
282 | The "Guard::guard" function comes in handy for any custom cleanup |
260 | you might want to do (but you cannot switch to other coroutines form |
283 | you might want to do (but you cannot switch to other coroutines from |
261 | those code blocks): |
284 | those code blocks): |
262 | |
285 | |
263 | async { |
286 | async { |
264 | my $window = new Gtk2::Window "toplevel"; |
287 | my $window = new Gtk2::Window "toplevel"; |
265 | # The window will not be cleaned up automatically, even when $window |
288 | # The window will not be cleaned up automatically, even when $window |
… | |
… | |
282 | 6. Viva La Zombie Muerte |
305 | 6. Viva La Zombie Muerte |
283 | Even after a thread has terminated and cleaned up its resources, the |
306 | Even after a thread has terminated and cleaned up its resources, the |
284 | Coro object still is there and stores the return values of the |
307 | Coro object still is there and stores the return values of the |
285 | thread. |
308 | thread. |
286 | |
309 | |
287 | The means the Coro object gets freed automatically when the thread |
310 | When there are no other references, it will simply be cleaned up and |
288 | has terminated and cleaned up and there arenot other references. |
311 | freed. |
289 | |
312 | |
290 | If there are, the Coro object will stay around, and you can call |
313 | If there areany references, the Coro object will stay around, and |
291 | "->join" as many times as you wish to retrieve the result values: |
314 | you can call "->join" as many times as you wish to retrieve the |
|
|
315 | result values: |
292 | |
316 | |
293 | async { |
317 | async { |
294 | print "hi\n"; |
318 | print "hi\n"; |
295 | 1 |
319 | 1 |
296 | }; |
320 | }; |
… | |
… | |
891 | But from within a coro, you often just want to write this: |
915 | But from within a coro, you often just want to write this: |
892 | |
916 | |
893 | my $status = wait_for_child $pid; |
917 | my $status = wait_for_child $pid; |
894 | |
918 | |
895 | Coro offers two functions specifically designed to make this easy, |
919 | Coro offers two functions specifically designed to make this easy, |
896 | "Coro::rouse_cb" and "Coro::rouse_wait". |
920 | "rouse_cb" and "rouse_wait". |
897 | |
921 | |
898 | The first function, "rouse_cb", generates and returns a callback that, |
922 | The first function, "rouse_cb", generates and returns a callback that, |
899 | when invoked, will save its arguments and notify the coro that created |
923 | when invoked, will save its arguments and notify the coro that created |
900 | the callback. |
924 | the callback. |
901 | |
925 | |
… | |
… | |
907 | function mentioned above: |
931 | function mentioned above: |
908 | |
932 | |
909 | sub wait_for_child($) { |
933 | sub wait_for_child($) { |
910 | my ($pid) = @_; |
934 | my ($pid) = @_; |
911 | |
935 | |
912 | my $watcher = AnyEvent->child (pid => $pid, cb => Coro::rouse_cb); |
936 | my $watcher = AnyEvent->child (pid => $pid, cb => rouse_cb); |
913 | |
937 | |
914 | my ($rpid, $rstatus) = Coro::rouse_wait; |
938 | my ($rpid, $rstatus) = rouse_wait; |
915 | $rstatus |
939 | $rstatus |
916 | } |
940 | } |
917 | |
941 | |
918 | In the case where "rouse_cb" and "rouse_wait" are not flexible enough, |
942 | In the case where "rouse_cb" and "rouse_wait" are not flexible enough, |
919 | you can roll your own, using "schedule" and "ready": |
943 | you can roll your own, using "schedule" and "ready": |