Merge pull request #56 from ntrel/patch-1

Author: DmitryOlshansky

README.md

@@ -5,11 +5,11 @@
 
 ## Intro
 
-Photon is a minimalistic multi-threaded fiber scheduler and event loop that works transparently with traditional blocking I/O C/C++/D/Rust libraries w/o degrading performance. For example one can run multituide of downloads with `std.net.curl` with fibers, no blocking - it is as fast as threads but using less resources. Think of it as Golang style concurrency that is brought to D transparently.
+Photon is a minimalistic multi-threaded fiber scheduler and event loop that works transparently with traditional blocking I/O C/C++/D/Rust libraries w/o degrading performance. For example one can run a multitude of downloads with `std.net.curl` with fibers, no blocking - it is as fast as threads but using less resources. Think of it as Golang style concurrency that is brought to D transparently.
 
-Just like its particle cousing, Photon’s nature is dual, seeking to unify 2 different concepts (such as async and blocking I/O) in many ways:
-Fibers and Threads can be mixed and matched in coherent way. 
-LibC syscall wrapper is overriden to be aware of D fiber scheduling and transparently uses the same eventloop if called on fiber and is passed through otherwise.
+Just like its particle cousin, Photon’s nature is dual, seeking to unify 2 different concepts (such as async and blocking I/O) in many ways:
+Fibers and Threads can be mixed and matched in a coherent way. 
+LibC syscall wrapper is overriden to be aware of D fiber scheduling and transparently uses the same eventloop if called on a fiber and is passed through otherwise.
 
 Explicit async model with tasks/futures could be integrated with pseudoblocking fiber scheduling,
 D Ranges with asynchronous event streams are a natural extension looking forward.
@@ -80,8 +80,8 @@ Specifically note the points of interaction 1-4:
 
 What's important to understand is that all of the above can be mixed and matched (and in fact inevitably will, if we are not careful). To underline the problem:
  - explicit async mixes well with explicit async of the same flavor, badly with any other model. But at least it's an explicit problem that can be solved on per use case basis.
- - pseudoblocking only works if everything is following pseudoblocking model, also explicit async can integrate passably well, any single blocking primitive rapidly degrades pseudoblocking model
-- finally blocking I/O is bane of all, it trivially spills through into any other model code with disastrous consequences
+ - pseudoblocking only works if everything is following a pseudoblocking model, also explicit async can integrate passably well, any single blocking primitive rapidly degrades pseudoblocking model
+- finally blocking I/O is the bane of all, it trivially spills through into any other model code with disastrous consequences
 
 The end result is a brittle ecosystem where even if you have a 3rd party "driver" for your database it is likely not compatible with your I/O scheme, and the most widely compatible scheme (blocking I/O) is not scalable. Some libraries have 2 versions - one on top of vibe.d sockets and the other on top of std.socket.
 
@@ -90,6 +90,6 @@ The end result is a brittle ecosystem where even if you have a 3rd party "driver
 This project is going for a bold approach to solve this problem once and for all:
 1. Replacing the libc syscall wrapper so that any blocking call relying on it (which is next to all) is transparently rewired to go through pseudoblocking runtime. All 3rd party libraries do fiber-aware pseudoblocking I/O automatically.
 2. The rest of the libraries that do explicit async I/O stay as their are, their syscall are passed through. In the future we will intercept them as well to re-route to our eventloop, basically emulating the likes of `select`, `poll` and `epoll` in user-space by reusing the same event cache.
-3. Finally vibe.d may produce a thin-shelled version that forward all of calls to blocking I/O to reuse our scheduler.
+3. Finally vibe.d may produce a thin-shelled version that forwards all calls to blocking I/O to reuse our scheduler.
 
-Note: the approach of overriding underlying libc facilities is not something new or uncalled for, e.g. jemalloc does it fitfully to replace default libc memory allocator.
+Note: the approach of overriding underlying libc facilities is not something new or uncalled for, e.g. jemalloc does it fitfully to replace the default libc memory allocator.