… | |
… | |
80 | |
80 | |
81 | our $idle; # idle handler |
81 | our $idle; # idle handler |
82 | our $main; # main coro |
82 | our $main; # main coro |
83 | our $current; # current coro |
83 | our $current; # current coro |
84 | |
84 | |
85 | our $VERSION = 5.13; |
85 | our $VERSION = 5.132; |
86 | |
86 | |
87 | 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); |
88 | our %EXPORT_TAGS = ( |
88 | our %EXPORT_TAGS = ( |
89 | 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)], |
90 | ); |
90 | ); |
… | |
… | |
346 | |
346 | |
347 | These functions are best understood by an example: The following function |
347 | These functions are best understood by an example: The following function |
348 | will change the current timezone to "Antarctica/South_Pole", which |
348 | will change the current timezone to "Antarctica/South_Pole", which |
349 | 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>, |
350 | which remember/change the current timezone and restore the previous |
350 | which remember/change the current timezone and restore the previous |
351 | value, respectively, the timezone is only changes for the coro that |
351 | value, respectively, the timezone is only changed for the coro that |
352 | installed those handlers. |
352 | installed those handlers. |
353 | |
353 | |
354 | use POSIX qw(tzset); |
354 | use POSIX qw(tzset); |
355 | |
355 | |
356 | async { |
356 | async { |
… | |
… | |
426 | the ready queue, do nothing and return false. |
426 | the ready queue, do nothing and return false. |
427 | |
427 | |
428 | This ensures that the scheduler will resume this coro automatically |
428 | This ensures that the scheduler will resume this coro automatically |
429 | once all the coro of higher priority and all coro of the same |
429 | once all the coro of higher priority and all coro of the same |
430 | priority that were put into the ready queue earlier have been resumed. |
430 | priority that were put into the ready queue earlier have been resumed. |
|
|
431 | |
|
|
432 | =item $coro->suspend |
|
|
433 | |
|
|
434 | Suspends the specified coro. A suspended coro works just like any other |
|
|
435 | coro, except that the scheduler will not select a suspended coro for |
|
|
436 | execution. |
|
|
437 | |
|
|
438 | Suspending a coro can be useful when you want to keep the coro from |
|
|
439 | running, but you don't want to destroy it, or when you want to temporarily |
|
|
440 | freeze a coro (e.g. for debugging) to resume it later. |
|
|
441 | |
|
|
442 | A scenario for the former would be to suspend all (other) coros after a |
|
|
443 | fork and keep them alive, so their destructors aren't called, but new |
|
|
444 | coros can be created. |
|
|
445 | |
|
|
446 | =item $coro->resume |
|
|
447 | |
|
|
448 | If the specified coro was suspended, it will be resumed. Note that when |
|
|
449 | the coro was in the ready queue when it was suspended, it might have been |
|
|
450 | unreadied by the scheduler, so an activation might have been lost. |
|
|
451 | |
|
|
452 | To avoid this, it is best to put a suspended coro into the ready queue |
|
|
453 | unconditionally, as every synchronisation mechanism must protect itself |
|
|
454 | against spurious wakeups, and the one in the Coro family certainly do |
|
|
455 | that. |
431 | |
456 | |
432 | =item $is_ready = $coro->is_ready |
457 | =item $is_ready = $coro->is_ready |
433 | |
458 | |
434 | Returns true iff the Coro object is in the ready queue. Unless the Coro |
459 | Returns true iff the Coro object is in the ready queue. Unless the Coro |
435 | object gets destroyed, it will eventually be scheduled by the scheduler. |
460 | object gets destroyed, it will eventually be scheduled by the scheduler. |