README.md in futuroscope-0.0.4 vs README.md in futuroscope-0.0.5

@@ -21,11 +21,11 @@
 method on in it will be forwarded to the block's return value.
 
 If the thread didn't finish yet, it will block the program's execution until
 it's finished. Otherwise, it will immediataly return its value.
 
-Futuroscope is tested on `MRI 1.9.3`, `MRI 2.0.0`, `JRuby` and `Rubinius`.
+Futuroscope is tested on `MRI 1.9.3`, `MRI 2.0.0`, `MRI 1.8.7`, `JRuby in 1.9 mode`, `JRuby in 1.8 mode`, `Rubinius 1.9 mode`, `Rubinius 1.8 mode` and `REE`.
 
 ## Installation
 
 Add this line to your application's Gemfile:
 
@@ -126,12 +126,35 @@
 
 If you're looking for other ways to improve your code performance via
 concurrency, you should probably deal directly with [Ruby's
 threads](http://ruby-doc.org/core-2.0/Thread.html).
 
-## Ideas for the future
+## Thread pool
 
-* Having a thread pool so you can limit maximum concurrency.
+Futures are scheduled in a thread pool that helps managing concurrency in a way
+that doesn't get out of hands. Also comes with great benefits since their
+threads are spawned at load time (and not in runtime).
+
+The default thread pool comes with a concurrency of 8 threads, which seems
+reasonable for the most use cases.
+
+The default thread pool can be replaced by a new pool with different 
+concurrency like this:
+
+```Ruby
+Futuroscope.default_pool = Futuroscope::Pool.new(24)
+```
+
+Also, each future can be scheduled to a different pool like this:
+
+```Ruby
+pool = Futuroscope::Pool.new(32)
+
+future = Future.new(pool){ :edballs }
+
+# Or with the convenience method
+future = future(pool){ :edballs }
+```
 
 ## Contributing
 
 1. Fork it
 2. Create your feature branch (`git checkout -b my-new-feature`)