… | |
… | |
391 | correctly. |
391 | correctly. |
392 | |
392 | |
393 | Example: exit on SIGINT |
393 | Example: exit on SIGINT |
394 | |
394 | |
395 | my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); |
395 | my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 }); |
|
|
396 | |
|
|
397 | Restart Behaviour |
|
|
398 | While restart behaviour is up to the event loop implementation, most |
|
|
399 | will not restart syscalls (that includes Async::Interrupt and AnyEvent's |
|
|
400 | pure perl implementation). |
|
|
401 | |
|
|
402 | Safe/Unsafe Signals |
|
|
403 | Perl signals can be either "safe" (synchronous to opcode handling) or |
|
|
404 | "unsafe" (asynchronous) - the former might get delayed indefinitely, the |
|
|
405 | latter might corrupt your memory. |
|
|
406 | |
|
|
407 | AnyEvent signal handlers are, in addition, synchronous to the event |
|
|
408 | loop, i.e. they will not interrupt your running perl program but will |
|
|
409 | only be called as part of the normal event handling (just like timer, |
|
|
410 | I/O etc. callbacks, too). |
396 | |
411 | |
397 | Signal Races, Delays and Workarounds |
412 | Signal Races, Delays and Workarounds |
398 | Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching |
413 | Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching |
399 | callbacks to signals in a generic way, which is a pity, as you cannot do |
414 | callbacks to signals in a generic way, which is a pity, as you cannot do |
400 | race-free signal handling in perl, requiring C libraries for this. |
415 | race-free signal handling in perl, requiring C libraries for this. |
… | |
… | |
1709 | it's built-in modules) are required to use it. |
1724 | it's built-in modules) are required to use it. |
1710 | |
1725 | |
1711 | That does not mean that AnyEvent won't take advantage of some additional |
1726 | That does not mean that AnyEvent won't take advantage of some additional |
1712 | modules if they are installed. |
1727 | modules if they are installed. |
1713 | |
1728 | |
1714 | This section epxlains which additional modules will be used, and how |
1729 | This section explains which additional modules will be used, and how |
1715 | they affect AnyEvent's operetion. |
1730 | they affect AnyEvent's operation. |
1716 | |
1731 | |
1717 | Async::Interrupt |
1732 | Async::Interrupt |
1718 | This slightly arcane module is used to implement fast signal |
1733 | This slightly arcane module is used to implement fast signal |
1719 | handling: To my knowledge, there is no way to do completely |
1734 | handling: To my knowledge, there is no way to do completely |
1720 | race-free and quick signal handling in pure perl. To ensure that |
1735 | race-free and quick signal handling in pure perl. To ensure that |
… | |
… | |
1723 | 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY). |
1738 | 10 seconds, look for $AnyEvent::MAX_SIGNAL_LATENCY). |
1724 | |
1739 | |
1725 | If this module is available, then it will be used to implement |
1740 | If this module is available, then it will be used to implement |
1726 | signal catching, which means that signals will not be delayed, and |
1741 | signal catching, which means that signals will not be delayed, and |
1727 | the event loop will not be interrupted regularly, which is more |
1742 | the event loop will not be interrupted regularly, which is more |
1728 | efficient (And good for battery life on laptops). |
1743 | efficient (and good for battery life on laptops). |
1729 | |
1744 | |
1730 | This affects not just the pure-perl event loop, but also other event |
1745 | This affects not just the pure-perl event loop, but also other event |
1731 | loops that have no signal handling on their own (e.g. Glib, Tk, Qt). |
1746 | loops that have no signal handling on their own (e.g. Glib, Tk, Qt). |
1732 | |
1747 | |
1733 | Some event loops (POE, Event, Event::Lib) offer signal watchers |
1748 | Some event loops (POE, Event, Event::Lib) offer signal watchers |
… | |
… | |
1775 | FORK |
1790 | FORK |
1776 | Most event libraries are not fork-safe. The ones who are usually are |
1791 | Most event libraries are not fork-safe. The ones who are usually are |
1777 | because they rely on inefficient but fork-safe "select" or "poll" calls. |
1792 | because they rely on inefficient but fork-safe "select" or "poll" calls. |
1778 | Only EV is fully fork-aware. |
1793 | Only EV is fully fork-aware. |
1779 | |
1794 | |
|
|
1795 | This means that, in general, you cannot fork and do event processing in |
|
|
1796 | the child if a watcher was created before the fork (which in turn |
|
|
1797 | initialises the event library). |
|
|
1798 | |
1780 | If you have to fork, you must either do so *before* creating your first |
1799 | If you have to fork, you must either do so *before* creating your first |
1781 | watcher OR you must not use AnyEvent at all in the child OR you must do |
1800 | watcher OR you must not use AnyEvent at all in the child OR you must do |
1782 | something completely out of the scope of AnyEvent. |
1801 | something completely out of the scope of AnyEvent. |
|
|
1802 | |
|
|
1803 | The problem of doing event processing in the parent *and* the child is |
|
|
1804 | much more complicated: even for backends that *are* fork-aware or |
|
|
1805 | fork-safe, their behaviour is not usually what you want: fork clones all |
|
|
1806 | watchers, that means all timers, I/O watchers etc. are active in both |
|
|
1807 | parent and child, which is almost never what you want. |
1783 | |
1808 | |
1784 | SECURITY CONSIDERATIONS |
1809 | SECURITY CONSIDERATIONS |
1785 | AnyEvent can be forced to load any event model via |
1810 | AnyEvent can be forced to load any event model via |
1786 | $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used |
1811 | $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used |
1787 | to execute arbitrary code or directly gain access, it can easily be used |
1812 | to execute arbitrary code or directly gain access, it can easily be used |