[ViewVC] Diff of: cvs/Coro/README

Comparing Coro/README (file contents):
Revision 1.35 by root, Wed Feb 11 19:30:34 2015 UTC vs.
Revision 1.39 by root, Fri Jul 14 13:14:32 2017 UTC

         program, as "async" does. As the coro is being reused, stuff like
         "on_destroy" will not work in the expected way, unless you call
         terminate or cancel, which somehow defeats the purpose of pooling
         (but is fine in the exceptional case).
-        The priority will be reset to 0 after each run, tracing will be
+        The priority will be reset to 0 after each run, all "swap_sv" calls
-        disabled, the description will be reset and the default output
+        will be undone, tracing will be disabled, the description will be
-        filehandle gets restored, so you can change all these. Otherwise the
+        reset and the default output filehandle gets restored, so you can
-        coro will be re-used "as-is": most notably if you change other
+        change all these. Otherwise the coro will be re-used "as-is": most
-        per-coro global stuff such as $/ you *must needs* revert that
+        notably if you change other per-coro global stuff such as $/ you
-        change, which is most simply done by using local as in: "local $/".
+        *must needs* revert that change, which is most simply done by using
+        local as in: "local $/".
         The idle pool size is limited to 8 idle coros (this can be adjusted
         by changing $Coro::POOL_SIZE), but there can be as many non-idle
         coros as required.
               # at this place, the timezone is Antarctica/South_Pole,
               # without disturbing the TZ of any other coro.
            };
         This can be used to localise about any resource (locale, uid,
-        current working directory etc.) to a block, despite the existance of
+        current working directory etc.) to a block, despite the existence of
         other coros.
         Another interesting example implements time-sliced multitasking
         using interval timers (this could obviously be optimised, but does
         the job):
     $state->is_new
         Returns true iff this Coro object is "new", i.e. has never been run
         yet. Those states basically consist of only the code reference to
         call and the arguments, but consumes very little other resources.
         New states will automatically get assigned a perl interpreter when
-        they are transfered to.
+        they are transferred to.
     $state->is_zombie
         Returns true iff the Coro object has been cancelled, i.e. it's
         resources freed because they were "cancel"'ed, "terminate"'d,
         "safe_cancel"'ed or simply went out of scope.
         otherwise you might suffer from crashes or worse. The only event
         library currently known that is safe to use without "unblock_sub" is
         EV (but you might still run into deadlocks if all event loops are
         blocked).
-        Coro will try to catch you when you block in the event loop
+        Coro will try to catch you when you block in the event loop ("FATAL:
-        ("FATAL:$Coro::idle blocked itself"), but this is just best effort
+        $Coro::idle blocked itself"), but this is just best effort and only
-        and only works when you do not run your own event loop.
+        works when you do not run your own event loop.
         This function allows your callbacks to block by executing them in
         another coro where it is safe to block. One example where blocking
         is handy is when you use the Coro::AIO functions to save results to
         disk, for example.
     It is very common for a coro to wait for some callback to be called.
     This occurs naturally when you use coro in an otherwise event-based
     program, or when you use event-based libraries.
     These typically register a callback for some event, and call that
-    callback when the event occured. In a coro, however, you typically want
+    callback when the event occurred. In a coro, however, you typically want
     to just wait for the event, simplyifying things.
     For example "AnyEvent->child" registers a callback to be called when a
     specific child has exited:
     processes. What makes it so bad is that on non-windows platforms, you
     can actually take advantage of custom hardware for this purpose (as
     evidenced by the forks module, which gives you the (i-) threads API,
     just much faster).
-    Sharing data is in the i-threads model is done by transfering data
+    Sharing data is in the i-threads model is done by transferring data
     structures between threads using copying semantics, which is very slow -
     shared data simply does not exist. Benchmarks using i-threads which are
     communication-intensive show extremely bad behaviour with i-threads (in
     fact, so bad that Coro, which cannot take direct advantage of multiple
     CPUs, is often orders of magnitude faster because it shares data using
     XS API: Coro::MakeMaker.
     Low level Configuration, Thread Environment, Continuations: Coro::State.
-AUTHOR
+AUTHOR/SUPPORT/CONTACT
-     Marc Lehmann <schmorp@schmorp.de>
+       Marc A. Lehmann <schmorp@schmorp.de>
-     http://home.schmorp.de/
+       http://software.schmorp.de/pkg/Coro.html

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing Coro/README (file contents): Revision 1.35 by root, Wed Feb 11 19:30:34 2015 UTC vs. Revision 1.39 by root, Fri Jul 14 13:14:32 2017 UTC

Diff Legend

Comparing Coro/README (file contents):
Revision 1.35 by root, Wed Feb 11 19:30:34 2015 UTC vs.
Revision 1.39 by root, Fri Jul 14 13:14:32 2017 UTC