[Guile-commits] 23/24: Minor editing in api-scheduling.texi

[Andy Wingo]

wingo pushed a commit to branch master
in repository guile.

commit 2c0c6414bb030eb3b185d8da427330666815a6ce
Author: Andy Wingo <address@hidden>
Date:   Sun Nov 6 18:29:05 2016 +0100

    Minor editing in api-scheduling.texi
    
    * doc/ref/api-scheduling.texi: Fix a couple editing mistakes.
---
 doc/ref/api-scheduling.texi |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/ref/api-scheduling.texi b/doc/ref/api-scheduling.texi
index c5015fb..1f5d17f 100644
--- a/doc/ref/api-scheduling.texi
+++ b/doc/ref/api-scheduling.texi
@@ -384,7 +384,7 @@ But if you arrange to unlock the mutex when leaving a 
dynamic extent via
 via a continuation invocation?  Surely re-entering the dynamic extent
 without the lock is a bad idea, so there are two options on the table:
 either prevent re-entry via @code{with-continuation-barrier} or similar,
-or reacquiring the lock in the entry thunk of a @code{dynamic-wind}.
+or reacquire the lock in the entry thunk of a @code{dynamic-wind}.
 
 You might think that because you don't use continuations, that you don't
 have to think about this, and you might be right.  If you control the
@@ -428,7 +428,7 @@ and like standard mutexes can only be unlocked by the owner 
thread.
 Finally, calling @code{make-mutex} with the symbol
 @code{allow-external-unlock} creates an unowned mutex.  An unowned mutex
 is like a standard mutex, except that it can be unlocked by any thread.
-A corrolary of this behavior is that a thread's attempt to lock a mutex
+A corollary of this behavior is that a thread's attempt to lock a mutex
 that it already owns will block instead of signalling an error, as it
 could be that some other thread unlocks the mutex, allowing the owner
 thread to proceed.  This kind of mutex is a bit strange and is here for