--- AnyEvent/README	2009/11/19 01:55:57	1.56
+++ AnyEvent/README	2009/12/05 02:52:03	1.57
@@ -394,6 +394,21 @@
 
        my $w = AnyEvent->signal (signal => "INT", cb => sub { exit 1 });
 
+   Restart Behaviour
+    While restart behaviour is up to the event loop implementation, most
+    will not restart syscalls (that includes Async::Interrupt and AnyEvent's
+    pure perl implementation).
+
+   Safe/Unsafe Signals
+    Perl signals can be either "safe" (synchronous to opcode handling) or
+    "unsafe" (asynchronous) - the former might get delayed indefinitely, the
+    latter might corrupt your memory.
+
+    AnyEvent signal handlers are, in addition, synchronous to the event
+    loop, i.e. they will not interrupt your running perl program but will
+    only be called as part of the normal event handling (just like timer,
+    I/O etc. callbacks, too).
+
    Signal Races, Delays and Workarounds
     Many event loops (e.g. Glib, Tk, Qt, IO::Async) do not support attaching
     callbacks to signals in a generic way, which is a pity, as you cannot do
@@ -1711,8 +1726,8 @@
     That does not mean that AnyEvent won't take advantage of some additional
     modules if they are installed.
 
-    This section epxlains which additional modules will be used, and how
-    they affect AnyEvent's operetion.
+    This section explains which additional modules will be used, and how
+    they affect AnyEvent's operation.
 
     Async::Interrupt
         This slightly arcane module is used to implement fast signal
@@ -1725,7 +1740,7 @@
         If this module is available, then it will be used to implement
         signal catching, which means that signals will not be delayed, and
         the event loop will not be interrupted regularly, which is more
-        efficient (And good for battery life on laptops).
+        efficient (and good for battery life on laptops).
 
         This affects not just the pure-perl event loop, but also other event
         loops that have no signal handling on their own (e.g. Glib, Tk, Qt).
@@ -1777,10 +1792,20 @@
     because they rely on inefficient but fork-safe "select" or "poll" calls.
     Only EV is fully fork-aware.
 
+    This means that, in general, you cannot fork and do event processing in
+    the child if a watcher was created before the fork (which in turn
+    initialises the event library).
+
     If you have to fork, you must either do so *before* creating your first
     watcher OR you must not use AnyEvent at all in the child OR you must do
     something completely out of the scope of AnyEvent.
 
+    The problem of doing event processing in the parent *and* the child is
+    much more complicated: even for backends that *are* fork-aware or
+    fork-safe, their behaviour is not usually what you want: fork clones all
+    watchers, that means all timers, I/O watchers etc. are active in both
+    parent and child, which is almost never what you want.
+
 SECURITY CONSIDERATIONS
     AnyEvent can be forced to load any event model via
     $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used