Ruby developers need to stop using EventMachine. It's the wrong direction. Lost in the "Threads vs Event Driven vs Process Spawning" debate is that you can combine them! Learn how Celluloid is improving thread programming by abstracting them using a higher level framework called Celluloid, how you can use Celluloid::IO to throw a reactor pattern into a thread. Using this approach, you can take advantage of threading and use all CPU power on a machine with JRuby or Rubinius. I also discuss the future of distributed objects and computing, and where I think things are going.

1. Threads and
Events in
Harmony with
Celluloid
Kyle Drake

2. Hi, I’m Kyle Drake. I
work at Geoloqi Esri.
We built a geofencing
Text
and real-time location
streaming platform.

3. Last year, IText a
did
talk at KRTConf.

4. I was really into
pure event-driven
Text
(reactor pattern
based) architecture.

5. EventMachine,
Twisted,
Node.js
• Event-driven
Text
• No threads
• One CPU core
• Process Spawning

6. I released
sinatra-synchrony,
so I could use
Text
EventMachine
without callbacks.

7. Since then, I’ve
Text
changed my mind.

8. I’m really not a fan
of EventMachine
Text
anymore.

9. EventMachine is
• A frankenstein - guts the ruby internals
• Not in active development
Text
• Makes non-blocking IO block
• Requires special code from Ruby libraries
• Hard to use in an OOP way
• Is really difficult to work with
• Poorly documented

10. Ruby developers
need to stop using
EventMachine. It’s
Text
the wrong
direction.

11. Check this
benchmark
Text
out:

12. Text
http://rhaas.blogspot.com/2012/04/did-i-say-32-cores-how-about-64.html

13. Predictions:
More Cores.
A lot more.

14. Predictions:
More libraries
=
more memory

15. Will process
spawning work
forever?
It might.

16. It might not.
Thousands of
cores?

18. Ruby MRI:
Global Interpreter Lock
(single CPU core)
Rubinius and JRuby:
Full threading
(multiple CPU cores)
~20KB per thread

19. We’re not finding
a lot of thread
safety issues in
Ruby.

20. “Threading is
hard”

21. Threading is
not an
intention!

22. Let’s fix it by
abstracting
threads into how
humans think!

24. http://celluloid.io
• Developed by Tony Arcieri
• Actor Pattern for Ruby
• Lots of inspiration from Erlang

25. Each actor is a
concurrent object
running in its own
thread

28. First “Killer App”:
Sidekiq
Mike Perham

30. Don’t get me
wrong. Event-
driven is still
awesome.

31. “..seasoned engineers are
using a mix of threaded,
event-based, and
alternative concurrency
approaches like Actors”
- Alex Payne

32. What if we could
combine threads
and reactor
patterns.. and
actors?!

33. https://github.com/celluloid/celluloid-io
• One reactor pattern per Celluloid object
• Multiple reactors? No problem!
• Doesn’t mess with code outside of actor
• Utilizes all CPU cores (using JRuby and Rubinius)
• Websockets, messaging systems, your hugely
successful blog

34. You don't have to
choose between
threaded and
evented IO!

35. Let’s get
distributed.

36. "I thought of objects being like
biological cells and/or
individual computers on a
network, only able to
communicate with messages"
- Alan Kay

37. Guess who was really
into distributed
network objects?

39. NeXT experimented
with distributed
objects in the mid 90s.
NeXT was way ahead
of its time.

40. "Objects can message objects transparently
that live on other machines over the network,
and you don't have to worry about the
networking gunk, and you don't have to worry
about finding them, and you don't have to
worry about anything. It's just as if you
messaged an object that's right next door."
- Steve Jobs

41. “Portable Distributed Objects”

42. https://github.com/celluloid/dcell
• Objects talk over networks!
• Uses 0MQ
• Aware of eachothers’ existence
• Distributed gossip protocol
• Web UI
• In the early stages, very promising

43. CODE
EXAMPLES!

44. Help Us
Build This!

45. Thanks!
@kyledrake
kyledrake.net