[PATCH 04/14] doc: Fix grammar and typos.

[Cyril Brulebois]

Signed-off-by: Cyril Brulebois <kibi at debian.org>
---
 doc/smartsched |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/smartsched b/doc/smartsched
index bd76274..4ef6db2 100644
--- a/doc/smartsched
+++ b/doc/smartsched
@@ -73,13 +73,13 @@ With a single client executing a stream of requests:
 	Dispatch calls ReadRequestFromClient which reads a buffer (4K)
 	full of requests from the client
 
-	The server executes requests from this buffer until it emptys,
+	The server executes requests from this buffer until it empties,
 	in two stages -- 10 requests at a time are executed in the
 	inner Dispatch loop, a buffer full of requests are executed
 	because WaitForSomething immediately returns if any clients
 	have complete requests pending in their input queues.
 
-	When the buffer finally emptys, the next call to ReadRequest
+	When the buffer finally empties, the next call to ReadRequest
 	FromClient will return zero and Dispatch will go back to
 	WaitForSomething; now that the client has no requests pending,
 	WaitForSomething will block in select again.  If the client
@@ -104,7 +104,7 @@ into select; ReadRequestFromClient causes the server to yield when the
 client request buffer doesn't contain a complete request.  When
 that buffer is executed quickly, the server spends a lot of time
 in select discovering that the same client again has input ready.  Thus
-the server also runs busy clients less efficiently than is would be
+the server also runs busy clients less efficiently than it would be
 possible.
 
 What to do.
@@ -191,7 +191,7 @@ updated in three ways:
 	return to normal priority.
 
  3.	Clients which receive user input are praised by having
- 	their priority rased until they reach some maximal
+ 	their priority raised until they reach some maximal
 	value, above normal priority.
 
 The effect of these changes is to both improve interactive application
-- 
1.7.5.3