← Back to branch summary

~ubuntu-branches/ubuntu/raring/libanyevent-perl/raring

« back to all changes in this revision

Viewing changes to README

  • Committer: Bazaar Package Importer
  • Author(s): Jonathan Yu
  • Date: 2009-12-05 07:57:53 UTC
  • mfrom: (1.2.11 upstream)
  • Revision ID: james.westby@ubuntu.com-20091205075753-0n84lsk40kc10fs2
Tags: 5.220-1
New upstream release

Show diffs side-by-side

added added

removed removed

Lines of Context:
README
394
394
 
395
395
       my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
396
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).
 
411
 
397
412
   Signal Races, Delays and Workarounds
398
413
    Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching
399
414
    callbacks to signals in a generic way, which is a pity, as you cannot do
1711
1726
    That does not mean that AnyEvent won't take advantage of some additional
1712
1727
    modules if they are installed.
1713
1728
 
1714
 
    This section epxlains which additional modules will be used, and how
1715
 
    they affect AnyEvent's operetion.
 
1729
    This section explains which additional modules will be used, and how
 
1730
    they affect AnyEvent's operation.
1716
1731
 
1717
1732
    Async::Interrupt
1718
1733
        This slightly arcane module is used to implement fast signal
1725
1740
        If this module is available, then it will be used to implement
1726
1741
        signal catching, which means that signals will not be delayed, and
1727
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
1745
        This affects not just the pure-perl event loop, but also other event
1731
1746
        loops that have no signal handling on their own (e.g. Glib, Tk, Qt).
1777
1792
    because they rely on inefficient but fork-safe "select" or "poll" calls.
1778
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
1799
    If you have to fork, you must either do so *before* creating your first
1781
1800
    watcher OR you must not use AnyEvent at all in the child OR you must do
1782
1801
    something completely out of the scope of AnyEvent.
1783
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.
 
1808
 
1784
1809
SECURITY CONSIDERATIONS
1785
1810
    AnyEvent can be forced to load any event model via
1786
1811
    $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used