Skip to content
Browse files

Fixed typos

  • Loading branch information...
1 parent 475d2f8 commit ffffa36234bcf97b77b05b71e5ddf573797af742 @testobsessed testobsessed committed Mar 21, 2013
Showing with 3 additions and 3 deletions.
  1. +3 −3 docs/design.md
View
6 docs/design.md
@@ -10,11 +10,11 @@ for a few reasons. 1) the rest of CF uses Sinatra rather than Rails and we
want to unify our http framework, 2) we are converging on Sequel rather than
Active Record for our ORM, so we want to unify this in the CC, 3) the previous
CC used hybrid event/fiber based concurrency model that cause a lot of issue
-with developers accidently blocking the event loop. While I'm generally in
+with developers accidentally blocking the event loop. While I'm generally in
favor of evented and/or fiber based systems when running at high levels of
concurency, the CC does not fit that usage pattern, so the trade offs are not
worth it. A thread per request is perfectly fine for the CC and avoids having
-to wory about eventloop blocking issues.
+to worry about eventloop blocking issues.
It should be noted that while what is left of the previous CC is now going
through a rewrite, we have actually been somewhat doing a refactoring in place
@@ -34,7 +34,7 @@ follows:
* NATS based communication with other CF components
Performing NATS communication in a threaded model requires an adapter between
-concurency models. This is done by adding an EventMachine#schedule_sync method
+concurrency models. This is done by adding an EventMachine#schedule_sync method
which is run on a thread other than the reactor thread, i.e. a thread for a
request or some other worker thread pool, and runs the provided block in the
reactor thread. It blocks the calling thread on the result and will return the

0 comments on commit ffffa36

Please sign in to comment.
Something went wrong with that request. Please try again.