--- AnyEvent/README	2013/08/21 08:40:28	1.71
+++ AnyEvent/README	2013/12/17 16:43:15	1.72
@@ -471,6 +471,10 @@
 
        my $done = AnyEvent->condvar;
   
+       # this forks and immediately calls exit in the child. this
+       # normally has all sorts of bad consequences for your parent,
+       # so take this as an example only. always fork and exec,
+       # or call POSIX::_exit, in real code.
        my $pid = fork or exit 5;
   
        my $w = AnyEvent->child (
@@ -720,7 +724,7 @@
         "end" before sending.
 
         The ping example mentioned above is slightly more complicated, as
-        the there are results to be passwd back, and the number of tasks
+        the there are results to be passed back, and the number of tasks
         that are begun can potentially be zero:
 
            my $cv = AnyEvent->condvar;
@@ -1123,6 +1127,18 @@
         fuses IO::AIO and AnyEvent together, giving AnyEvent access to
         event-based file I/O, and much more.
 
+    AnyEvent::Fork, AnyEvent::Fork::RPC, AnyEvent::Fork::Pool,
+    AnyEvent::Fork::Remote
+        These let you safely fork new subprocesses, either locally or
+        remotely (e.g.v ia ssh), using some RPC protocol or not, without the
+        limitations normally imposed by fork (AnyEvent works fine for
+        example). Dynamically-resized worker pools are obviously included as
+        well.
+
+        And they are quite tiny and fast as well - "abusing" AnyEvent::Fork
+        just to exec external programs can easily beat using "fork" and
+        "exec" (or even "system") in most programs.
+
     AnyEvent::Filesys::Notify
         AnyEvent is good for non-blocking stuff, but it can't detect file or
         path changes (e.g. "watch this directory for new files", "watch this
@@ -1133,16 +1149,13 @@
         transparently on other platforms, so it's about as portable as it
         gets.
 
-        (I haven't used it myself, but I haven't heard anybody complaining
-        about it yet).
+        (I haven't used it myself, but it seems the biggest problem with it
+        is it quite bad performance).
 
     AnyEvent::DBI
         Executes DBI requests asynchronously in a proxy process for you,
         notifying you in an event-based way when the operation is finished.
 
-    AnyEvent::HTTPD
-        A simple embedded webserver.
-
     AnyEvent::FastPing
         The fastest ping in the west.
 
@@ -2037,17 +2050,34 @@
 
     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.
+    something completely out of the scope of AnyEvent (see below).
 
     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. USing "exec" to
-    start worker children from some kind of manage rprocess is usually
+    parent and child, which is almost never what you want. Using "exec" to
+    start worker children from some kind of manage prrocess is usually
     preferred, because it is much easier and cleaner, at the expense of
     having to have another binary.
 
+    In addition to logical problems with fork, there are also implementation
+    problems. For example, on POSIX systems, you cannot fork at all in Perl
+    code if a thread (I am talking of pthreads here) was ever created in the
+    process, and this is just the tip of the iceberg. In general, using fork
+    from Perl is difficult, and attempting to use fork without an exec to
+    implement some kind of parallel processing is almost certainly doomed.
+
+    To safely fork and exec, you should use a module such as Proc::FastSpawn
+    that let's you safely fork and exec new processes.
+
+    If you want to do multiprocessing using processes, you can look at the
+    AnyEvent::Fork module (and some related modules such as
+    AnyEvent::Fork::RPC, AnyEvent::Fork::Pool and AnyEvent::Fork::Remote).
+    This module allows you to safely create subprocesses without any
+    limitations - you can use X11 toolkits or AnyEvent in the children
+    created by AnyEvent::Fork safely and without any special precautions.
+
 SECURITY CONSIDERATIONS
     AnyEvent can be forced to load any event model via
     $ENV{PERL_ANYEVENT_MODEL}. While this cannot (to my knowledge) be used