Actor-based concurrent object framework for Ruby
Ruby
Latest commit 0da7638 Jul 18, 2016 @chuckremes chuckremes committed on GitHub add details on supervision
Failed to load latest commit information.
benchmarks consolidated the majority of rspec related testing code, finalizing a… Sep 25, 2015
culture @ 0a8899f updates to culture submodule Jun 9, 2016
examples rubocop cleaning Aug 6, 2015
lib Only use wacky Fiber.yield hack on Ruby Jul 14, 2016
log Log tests to log/test.log Aug 2, 2012
spec make sure log path exists before trying to open a file there Jun 24, 2016
tasks Closes #424 Aug 5, 2015
.atomignore complete removal of rspec-logsplit and reduction of dependencies cell… Sep 22, 2015
.coveralls.yml Coveralls support Mar 13, 2013
.document Holy whitespace, Batman May 30, 2012
.env-ci split spec_helper into support files Apr 15, 2015
.env-dev split spec_helper into support files Apr 15, 2015
.gitignore complete removal of rspec-logsplit and reduction of dependencies cell… Sep 22, 2015
.gitmodules Fix name of `Service` instances, prepare culture/rubocop Apr 28, 2015
.rspec avoid RSpec monkey-patching and explicit require Mar 10, 2015
.rubocop.yml Fix name of `Service` instances, prepare culture/rubocop Apr 28, 2015
.travis.yml Revert "Add RBX-3 to the build." Apr 19, 2016
CHANGES.md Bump version to 0.17.3 and update CHANGES.md Jan 17, 2016
CONDUCT.md move bundler back into spec_helper Sep 25, 2015
CONTRIBUTING.md Advise to load submodules for using pre-release [ci skip] Aug 17, 2015
DEPRECATION.md Update deprecation note Sep 22, 2015
Gemfile even tighter Gemfile handling May 7, 2015
Guardfile rubocop pass for celluloid/culture#33 Sep 28, 2015
LICENSE.txt Update copyright notice to 2016 [ci skip] Jan 3, 2016
README.md Tweaks to recent road-sign Jun 9, 2016
Rakefile minor linefeed additions Aug 13, 2015
architecture.md add details on supervision Jul 18, 2016
celluloid.gemspec require ruby 1.9.3+ Sep 19, 2015

README.md

Celluloid

Gem Version Build Status Code Climate Coverage Status

"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages" --Alan Kay, creator of Smalltalk, on the meaning of "object oriented programming"

Celluloid provides a simple and natural way to build fault-tolerant concurrent programs in Ruby. With Celluloid, you can build systems out of concurrent objects just as easily as you build sequential programs out of regular objects. Recommended for any developer, including novices, Celluloid should help ease your worries about building multithreaded Ruby programs.

Much of the difficulty with building concurrent programs in Ruby arises because the object-oriented mechanisms for structuring code, such as classes and inheritance, are separate from the concurrency mechanisms, such as threads and locks. Celluloid combines these into a single structure, an active object running within a thread, called an "actor", or in Celluloid vernacular, a "cell".

By combining concurrency with object oriented programming, Celluloid frees you up from worry about where to use threads and locks. Celluloid combines them together into a single concurrent object oriented programming model, encapsulating state in concurrent objects and thus avoiding many of the problems associated with multithreaded programming. Celluloid provides many features which make concurrent programming simple, easy, and fun:

  • Automatic "deadlock-free" synchronization: Celluloid uses a concurrent object model which combines method dispatch and thread synchronization. Each actor is a concurrent object running in its own thread, and every method invocation is wrapped in a fiber that can be suspended whenever it calls out to other actors, and resumed when the response is available. This means methods which are waiting for responses from other actors, external messages, or other system events (including I/O with Celluloid::IO) can be suspended and will never block other methods that are ready to run. This won't prevent bugs in Celluloid, bugs in other thread-safe libraries you use, and even certain "dangerous" features of Celluloid from causing your program to deadlock, but in general, programs built with Celluloid will be naturally immune to deadlocks.

  • Fault-tolerance: Celluloid has taken to heart many of Erlang's ideas about fault-tolerance in order to enable self-healing applications. The central idea: have you tried turning it off and on again? Celluloid takes care of rebooting subcomponents of your application when they crash, whether it's a single actor, or large (potentially multi-tiered) groups of actors that are all interdependent. This means rather than worrying about rescuing every last exception, you can just sit back, relax, and let parts of your program crash, knowing Celluloid will automatically reboot them in a clean state. Celluloid provides its own implementation of the core fault-tolerance concepts in Erlang including linking, supervisors, and supervision groups.

  • Futures: Ever wanted to call a method "in the background" and retrieve the value it returns later? Celluloid futures do just that. It's like calling ahead to a restaurant to place an order, so they can work on preparing your food while you're on your way to pick it up. When you ask for a method's return value, it's returned immediately if the method has already completed, or otherwise the current method is suspended until the value becomes available.

You can also build distributed systems with Celluloid using its sister project DCell. Evented IO similar to EventMachine (with a synchronous API instead of callback/deferrable soup) is available through the Celluloid::IO library.

Like Celluloid? Join the mailing list/Google Group or visit us on IRC at #celluloid on freenode

Is it any good?

Yes

Is It "Production Ready™"?

Yes, many users are now running Celluloid in production.

Documentation

Please see the Celluloid Wiki for more detailed documentation and usage notes.

The following API documentation is also available:

Related Projects

Celluloid is the parent project of a related ecosystem of other projects. If you like Celluloid we definitely recommend you check them out:

  • Reel: An "evented" web server based on Celluloid::IO
  • DCell: The Celluloid actor protocol distributed over 0MQ
  • ECell: Mesh strategies for Celluloid actors distributed over 0MQ
  • Celluloid::IO: "Evented" IO support for Celluloid actors
  • Celluloid::ZMQ: "Evented" 0MQ support for Celluloid actors
  • Celluloid::DNS: An "evented" DNS server based on Celluloid::IO
  • Celluloid::SMTP: An "evented" SMTP server based on Celluloid::IO
  • Lattice: A concurrent realtime web framework based on Celluloid::IO
  • nio4r: "New IO for Ruby": high performance IO selectors
  • Timers: A generic Ruby timer library for event-based systems

Installation

Add this line to your application's Gemfile:

gem 'celluloid'

And then execute:

$ bundle

Or install it yourself as:

$ gem install celluloid

Inside of your Ruby program, require Celluloid with newest API:

require 'celluloid/current'

Or to support the old API, use:

require 'celluloid/backported'

Cloning via GitHub

Right now Celluloid has a submodule. To install the framework via GitHub, you need to clone the submodules as well.

Clone from scratch:

$ git clone --recursive https://github.com/celluloid/celluloid

If you already cloned Celluloid without submodules:

Run the following command in the directory containing Celluloid:

git submodule update --init --recursive

Supported Platforms

Celluloid works on Ruby 2.0+, JRuby 1.7+, and Rubinius 2.0.

JRuby or Rubinius are the preferred platforms as they support true thread-level parallelism when executing Ruby code, whereas MRI/YARV is constrained by a global interpreter lock (GIL) and can only execute one thread at a time.

Celluloid requires Ruby 1.9 mode or higher on all interpreters.

Additional Reading

Contributing to Celluloid

  • Fork this repository on github
  • Make your changes and send us a pull request
  • If we like them we'll merge them
  • If we've accepted a patch, feel free to ask for commit access

License

Copyright (c) 2011-2015 Tony Arcieri, Donovan Keme.

Distributed under the MIT License. See LICENSE.txt for further details.