diff --git a/winsup/cygwin/how-signals-work.txt b/winsup/cygwin/how-signals-work.txt
index 710ce39d4..7ab85db8b 100644
--- a/winsup/cygwin/how-signals-work.txt
+++ b/winsup/cygwin/how-signals-work.txt
@@ -111,7 +111,7 @@ signal" value and sets errno to this, if so.  Finally, it restores all
 of the register values that were in effect when sigdelayed was called.
 
 Ok, you thought I had forgotten about the 'pending' stuff didn't you?
-Well, if you can rewind up to the discussion of sig_handle we'll return
+Well, if you can rewind up to the discussion of sig_handle, we'll return
 to the situation where sigsave was currently active.  In this case,
 setup_handler will set a "pending" flag, will reincrement the appropriate
 element of the above signal array, and will return 0 to indicate that
@@ -119,9 +119,10 @@ the interrupt did not occur.  Otherwise setup_handler returns 1.
 
 For pending signals, the theory is that the signal handler thread will
 be forced to be rerun by having some strategic cygwin function call
-sig_send with a __SIGFLUSH argument.  This causes the signal handler
-to rescan the signal array looking for pending signals.
+sig_send with a __SIGFLUSH "argument" to it.  This causes the signal
+handler to rescan the signal array looking for pending signals.
 
 This leads us to the sig_send function.  This is the "client side" part
 of the signal manipulation process.  sig_send is the low-level function
-called by a high level process like kill().
+called by a high level process like kill().  You would use sig_send
+to send a __SIGFLUSH to the signal thread.