17. Process Concurrency
•Requires you to start/monitor each process
•Requires some type of RPC (dRb, Resque, etc)
•Can’t share resources (like connection pools)
•Memory inefficient w/o copy-on-write
•One process per core
18. Thread Concurrency
http://blog.carbonfive.com/2011/10/11/a-modern-guide-to-threads/
Concurrency within a
19. Thread Concurrency
http://blog.carbonfive.com/2011/10/11/a-modern-guide-to-threads/
Concurrency within a
34. Thread Pros
•More intuitive than fibers/events
•Sans GIL: most efficient/performant* technique
•Single process to monitor
•Shared resources, no RPC
•Fine-grained control of thread lifecycle
*http://teddziuba.com/2011/10/straight-talk-on-event-loops.html
42. Fiber Concurrency
•Code blocks that can be paused/resumed
•Lighter than threads, cannot be preempted
•Scheduled by programmer
•Can share data without mutexes
Manually scheduled
46. Fiber Pros
•Much lighter memory use than threads
•Faster to start vs threads
•Can share data without mutex
•Can simplify asynchronous APIs (em-synchrony)
Text
47. Fiber Cons
•Limited to one CPU core
•Nonintuitive
•Syntax can get confusing
•Need to use fiber-aware libraries for I/O
Text
52. EventMachine Cons
•Inversion of control can be confusing
•Hard to test
•Nested callbacks can lead to spaghetti code
•Threads can still beat events (all apps will
eventually become CPU bound)