On 03/12/2014 06:22 AM, Samuel Williams wrote:
> Threads are good but I felt like I wanted something more predictable.
> Also, not all implementations of Ruby use green threads and therefore
> might have synchronisation issues if you use (either directly or
> indirectly through a gem/library) shared global state.

Even green threads have this danger, don't they?

Taking over manual scheduling seems a bit awkward compared to using some 
kind of concurrency control (mutexes, queues, actors). What happens if 
application code inside the fiber (process_and_email_results in the 
example) makes a blocking IO call?

Manual scheduling with fibers is great for testing concurrent code which 
would otherwise run in threads, because you can force a certain kind of 
contention in a predicable way. I'm working on extracting a library for 
doing this from a project where it's been a useful technique.