[PATCH 04/14] doc: Fix grammar and typos.
Cyril Brulebois
kibi at debian.org
Sun Jun 5 17:25:02 PDT 2011
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
More information about the xorg-devel
mailing list