… | |
… | |
40 | points in your program, so locking and parallel access are rarely an |
40 | points in your program, so locking and parallel access are rarely an |
41 | issue, making thread programming much safer and easier than using other |
41 | issue, making thread programming much safer and easier than using other |
42 | thread models. |
42 | thread models. |
43 | |
43 | |
44 | Unlike the so-called "Perl threads" (which are not actually real threads |
44 | Unlike the so-called "Perl threads" (which are not actually real threads |
45 | but only the windows process emulation ported to unix), Coro provides a |
45 | but only the windows process emulation ported to unix, and as such act |
46 | full shared address space, which makes communication between threads |
46 | as processes), Coro provides a full shared address space, which makes |
47 | very easy. And threads are fast, too: disabling the Windows process |
47 | communication between threads very easy. And Coro's threads are fast, |
48 | emulation code in your perl and using Coro can easily result in a two to |
48 | too: disabling the Windows process emulation code in your perl and using |
49 | four times speed increase for your programs. |
49 | Coro can easily result in a two to four times speed increase for your |
|
|
50 | programs. A parallel matrix multiplication benchmark runs over 300 times |
|
|
51 | faster on a single core than perl's pseudo-threads on a quad core using |
|
|
52 | all four cores. |
50 | |
53 | |
51 | Coro achieves that by supporting multiple running interpreters that share |
54 | Coro achieves that by supporting multiple running interpreters that share |
52 | data, which is especially useful to code pseudo-parallel processes and |
55 | data, which is especially useful to code pseudo-parallel processes and |
53 | for event-based programming, such as multiple HTTP-GET requests running |
56 | for event-based programming, such as multiple HTTP-GET requests running |
54 | concurrently. See L<Coro::AnyEvent> to learn more on how to integrate Coro |
57 | concurrently. See L<Coro::AnyEvent> to learn more on how to integrate Coro |
55 | into an event-based environment. |
58 | into an event-based environment. |
56 | |
59 | |
57 | In this module, a thread is defined as "callchain + lexical variables + |
60 | In this module, a thread is defined as "callchain + lexical variables + |
58 | @_ + $_ + $@ + $/ + C stack), that is, a thread has its own callchain, |
61 | some package variables + C stack), that is, a thread has its own callchain, |
59 | its own set of lexicals and its own set of perls most important global |
62 | its own set of lexicals and its own set of perls most important global |
60 | variables (see L<Coro::State> for more configuration and background info). |
63 | variables (see L<Coro::State> for more configuration and background info). |
61 | |
64 | |
62 | See also the C<SEE ALSO> section at the end of this document - the Coro |
65 | See also the C<SEE ALSO> section at the end of this document - the Coro |
63 | module family is quite large. |
66 | module family is quite large. |
… | |
… | |
77 | |
80 | |
78 | our $idle; # idle handler |
81 | our $idle; # idle handler |
79 | our $main; # main coro |
82 | our $main; # main coro |
80 | our $current; # current coro |
83 | our $current; # current coro |
81 | |
84 | |
82 | our $VERSION = 5.13; |
85 | our $VERSION = 5.132; |
83 | |
86 | |
84 | our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub); |
87 | our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub); |
85 | our %EXPORT_TAGS = ( |
88 | our %EXPORT_TAGS = ( |
86 | prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)], |
89 | prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)], |
87 | ); |
90 | ); |
… | |
… | |
335 | |
338 | |
336 | These functions implement the same concept as C<dynamic-wind> in scheme |
339 | These functions implement the same concept as C<dynamic-wind> in scheme |
337 | does, and are useful when you want to localise some resource to a specific |
340 | does, and are useful when you want to localise some resource to a specific |
338 | coro. |
341 | coro. |
339 | |
342 | |
340 | They slow down coro switching considerably for coros that use |
343 | They slow down thread switching considerably for coros that use them |
341 | them (But coro switching is still reasonably fast if the handlers are |
344 | (about 40% for a BLOCK with a single assignment, so thread switching is |
342 | fast). |
345 | still reasonably fast if the handlers are fast). |
343 | |
346 | |
344 | These functions are best understood by an example: The following function |
347 | These functions are best understood by an example: The following function |
345 | will change the current timezone to "Antarctica/South_Pole", which |
348 | will change the current timezone to "Antarctica/South_Pole", which |
346 | requires a call to C<tzset>, but by using C<on_enter> and C<on_leave>, |
349 | requires a call to C<tzset>, but by using C<on_enter> and C<on_leave>, |
347 | which remember/change the current timezone and restore the previous |
350 | which remember/change the current timezone and restore the previous |
348 | value, respectively, the timezone is only changes for the coro that |
351 | value, respectively, the timezone is only changed for the coro that |
349 | installed those handlers. |
352 | installed those handlers. |
350 | |
353 | |
351 | use POSIX qw(tzset); |
354 | use POSIX qw(tzset); |
352 | |
355 | |
353 | async { |
356 | async { |
… | |
… | |
370 | }; |
373 | }; |
371 | |
374 | |
372 | This can be used to localise about any resource (locale, uid, current |
375 | This can be used to localise about any resource (locale, uid, current |
373 | working directory etc.) to a block, despite the existance of other |
376 | working directory etc.) to a block, despite the existance of other |
374 | coros. |
377 | coros. |
|
|
378 | |
|
|
379 | Another interesting example implements time-sliced multitasking using |
|
|
380 | interval timers (this could obviously be optimised, but does the job): |
|
|
381 | |
|
|
382 | # "timeslice" the given block |
|
|
383 | sub timeslice(&) { |
|
|
384 | use Time::HiRes (); |
|
|
385 | |
|
|
386 | Coro::on_enter { |
|
|
387 | # on entering the thread, we set an VTALRM handler to cede |
|
|
388 | $SIG{VTALRM} = sub { cede }; |
|
|
389 | # and then start the interval timer |
|
|
390 | Time::HiRes::setitimer &Time::HiRes::ITIMER_VIRTUAL, 0.01, 0.01; |
|
|
391 | }; |
|
|
392 | Coro::on_leave { |
|
|
393 | # on leaving the thread, we stop the interval timer again |
|
|
394 | Time::HiRes::setitimer &Time::HiRes::ITIMER_VIRTUAL, 0, 0; |
|
|
395 | }; |
|
|
396 | |
|
|
397 | &{+shift}; |
|
|
398 | } |
|
|
399 | |
|
|
400 | # use like this: |
|
|
401 | timeslice { |
|
|
402 | # The following is an endless loop that would normally |
|
|
403 | # monopolise the process. Sicne it runs in a timeslice |
|
|
404 | # environment, it will regularly cede to other threads. |
|
|
405 | while () { } |
|
|
406 | }; |
|
|
407 | |
375 | |
408 | |
376 | =item killall |
409 | =item killall |
377 | |
410 | |
378 | Kills/terminates/cancels all coros except the currently running one. |
411 | Kills/terminates/cancels all coros except the currently running one. |
379 | |
412 | |
… | |
… | |
423 | the ready queue, do nothing and return false. |
456 | the ready queue, do nothing and return false. |
424 | |
457 | |
425 | This ensures that the scheduler will resume this coro automatically |
458 | This ensures that the scheduler will resume this coro automatically |
426 | once all the coro of higher priority and all coro of the same |
459 | once all the coro of higher priority and all coro of the same |
427 | priority that were put into the ready queue earlier have been resumed. |
460 | priority that were put into the ready queue earlier have been resumed. |
|
|
461 | |
|
|
462 | =item $coro->suspend |
|
|
463 | |
|
|
464 | Suspends the specified coro. A suspended coro works just like any other |
|
|
465 | coro, except that the scheduler will not select a suspended coro for |
|
|
466 | execution. |
|
|
467 | |
|
|
468 | Suspending a coro can be useful when you want to keep the coro from |
|
|
469 | running, but you don't want to destroy it, or when you want to temporarily |
|
|
470 | freeze a coro (e.g. for debugging) to resume it later. |
|
|
471 | |
|
|
472 | A scenario for the former would be to suspend all (other) coros after a |
|
|
473 | fork and keep them alive, so their destructors aren't called, but new |
|
|
474 | coros can be created. |
|
|
475 | |
|
|
476 | =item $coro->resume |
|
|
477 | |
|
|
478 | If the specified coro was suspended, it will be resumed. Note that when |
|
|
479 | the coro was in the ready queue when it was suspended, it might have been |
|
|
480 | unreadied by the scheduler, so an activation might have been lost. |
|
|
481 | |
|
|
482 | To avoid this, it is best to put a suspended coro into the ready queue |
|
|
483 | unconditionally, as every synchronisation mechanism must protect itself |
|
|
484 | against spurious wakeups, and the one in the Coro family certainly do |
|
|
485 | that. |
428 | |
486 | |
429 | =item $is_ready = $coro->is_ready |
487 | =item $is_ready = $coro->is_ready |
430 | |
488 | |
431 | Returns true iff the Coro object is in the ready queue. Unless the Coro |
489 | Returns true iff the Coro object is in the ready queue. Unless the Coro |
432 | object gets destroyed, it will eventually be scheduled by the scheduler. |
490 | object gets destroyed, it will eventually be scheduled by the scheduler. |