--- Coro/README	2017/08/31 16:28:49	1.40
+++ Coro/README	2019/08/23 08:01:13	1.41
@@ -68,7 +68,7 @@
     through a number of states:
 
     1. Creation
-        The first thing in the life of a coro thread is it's creation -
+        The first thing in the life of a coro thread is its creation -
         obviously. The typical way to create a thread is to call the "async
         BLOCK" function:
 
@@ -87,7 +87,7 @@
 
         "async" will return a Coro object - you can store this for future
         reference or ignore it - a thread that is running, ready to run or
-        waiting for some event is alive on it's own.
+        waiting for some event is alive on its own.
 
         Another way to create a thread is to call the "new" constructor with
         a code-reference:
@@ -241,7 +241,7 @@
         anywhere, the thread is initially referenced because it is in the
         ready queue, when it runs it is referenced by $Coro::current, but
         when it calls "schedule", it gets "cancel"ed causing the guard
-        object to be destroyed (see the next section), and printing it's
+        object to be destroyed (see the next section), and printing its
         message.
 
         If this seems a bit drastic, remember that this only happens when
@@ -254,9 +254,9 @@
         returned when a thread terminates, during clean-up.
 
         Cleanup is quite similar to throwing an uncaught exception: perl
-        will work it's way up through all subroutine calls and blocks. On
-        it's way, it will release all "my" variables, undo all "local"'s and
-        free any other resources truly local to the thread.
+        will work its way up through all subroutine calls and blocks. On its
+        way, it will release all "my" variables, undo all "local"'s and free
+        any other resources truly local to the thread.
 
         So, a common way to free resources is to keep them referenced only
         by my variables:
@@ -286,7 +286,7 @@
            async {
               my $window = new Gtk2::Window "toplevel";
               # The window will not be cleaned up automatically, even when $window
-              # gets freed, so use a guard to ensure it's destruction
+              # gets freed, so use a guard to ensure its destruction
               # in case of an error:
               my $window_guard = Guard::guard { $window->destroy };
 
@@ -631,7 +631,7 @@
         they are transferred to.
 
     $state->is_zombie
-        Returns true iff the Coro object has been cancelled, i.e. it's
+        Returns true iff the Coro object has been cancelled, i.e. its
         resources freed because they were "cancel"'ed, "terminate"'d,
         "safe_cancel"'ed or simply went out of scope.
 
@@ -785,7 +785,7 @@
 
     $coro->on_destroy (\&cb)
         Registers a callback that is called when this coro thread gets
-        destroyed, that is, after it's resources have been freed but before
+        destroyed, that is, after its resources have been freed but before
         it is joined. The callback gets passed the terminate/cancel
         arguments, if any, and *must not* die, under any circumstances.