README.md in celluloid-io-0.12.1 vs README.md in celluloid-io-0.13.0.pre
- old
+ new
@@ -1,9 +1,10 @@
![Celluloid](https://github.com/celluloid/celluloid-io/raw/master/logo.png)
=============
[![Build Status](https://secure.travis-ci.org/celluloid/celluloid-io.png?branch=master)](http://travis-ci.org/celluloid/celluloid-io)
[![Dependency Status](https://gemnasium.com/celluloid/celluloid-io.png)](https://gemnasium.com/celluloid/celluloid-io)
+[![Code Climate](https://codeclimate.com/badge.png)](https://codeclimate.com/github/celluloid/celluloid-io)
You don't have to choose between threaded and evented IO! Celluloid::IO
provides an event-driven IO system for building fast, scalable network
applications that integrates directly with the
[Celluloid actor library](https://github.com/celluloid/celluloid), making it
@@ -32,9 +33,40 @@
to monitor IO objects, which provides cross-platform and cross-Ruby
implementation access to high-performance system calls such as epoll
and kqueue.
Like Celluloid::IO? [Join the Google Group](http://groups.google.com/group/celluloid-ruby)
+
+When should I use Celluloid::IO?
+--------------------------------
+
+Unlike systems like Node.js, Celluloid does not require that all I/O be
+"evented". Celluloid fully supports any libraries that support blocking I/O
+and for the *overwhelming majority* of use cases blocking I/O is more than
+sufficient. Using blocking I/O means that any Ruby library you want will
+Just Work without resorting to any kind of theatrics.
+
+Celluloid::IO exists for a few reasons:
+
+* During a blocking I/O operation, Celluloid actors cannot respond to incoming
+ messages to their mailboxes. They will process messages as soon as the
+ method containing a blocking I/O operation completes, however until this
+ happens the entire actor is blocked. If you would like to multiplex both
+ message processing and I/O operations, you will want to use Celluloid::IO.
+ This is especially important for *indefinite* blocking operations, such as
+ listening for incoming TCP connections.
+* Celluloid uses a native thread per actor. While native threads aren't
+ particularly expensive in Ruby (~20kB of RAM), you can use less RAM using
+ Celluloid::IO. You might consider using Celluloid::IO over an
+ actor-per-connection if you are dealing with 10,000 connections or more.
+* The goal of Celluloid::IO is to fully integrate it into the Celluloid
+ ecosystem, including DCell. DCell will hopefully eventually support
+ serializable I/O handles that you can seamlessly transfer between nodes.
+
+All that said, if you are just starting out with Celluloid, you probably want
+to start off using blocking I/O until you understand the fundamentals of
+Celluloid and have encountered one of the above reasons for switching
+over to Celluloid::IO.
Supported Platforms
-------------------
Celluloid::IO requires Ruby 1.9 support on all Ruby VMs.