v1.0.0 Roadmap

[jdantonio]

The other day @chrisseaton suggested to me that we should begin to plan what 1.0.0 will look like. I think this is an excellent idea. When I started this gem I was just creating a bunch of tools that I thought might be useful. I did not plan a feature set. I am open to all ideas and suggestions. We will use this thread to collectively create a new roadmap.

Below are a few things I would like to accomplish on the way to 1.0.0. These ideas are just a starting point.

Simple, Robust Actors

The actor model is becoming a very popular approach to concurrency. As an Erlang programmer I am partial to Erlang's processes, but they are tightly coupled to features of the Erlang runtime that we can't do in Ruby. I'd like an Actor implementation that supports a couple of key features:

• Supports both local and remote messaging
• Pluggable transport layer for remote actor
• Supports supervision
• Simple, fluent, and easy to use (no deep coupling and unnecessary internal complexity like many actor frameworks)

More Low Low Level Abstractions

There are many advanced concurrency abstractions in other languages that provide powerful, unique features. These abstractions may not have the broad appeal of Future but they make for an excellent "toolbox" for concurrency. They are also great building blocks for the high level abstractions. I'd like to see more of these in the gem. Some examples include:

• Parallel enumerations, like the .NET Parallel class
• Exchanger, CyclicBarrier, (suggested by @mighe) and other cool stuff from java.util.concurrent
• Simple Software Transactional Memory

More JRuby Optimizations

I hope this gem always remains interpreter-agnostic and I plan to always test against MRI/CRuby, JRuby, and Rubinius, but the JVM is definitely very friendly concurrency/parallelism. We've already implemented a few JVM-specific optimizations (AtomicFixnum and ThreadLocalVar) but I'd like to see us do this as often as possible.

[mighe]

Parallel collections are wonderful, especially when the interface is well written.
Scala uses under the hood the fork-join Java framework, that is a very very useful abstraction with divide-et-impera algorithms.
Maybe we could start from fork-join and then implement parallel collecations

[jdantonio]

Something I forgot to mention in my first post: Better handling of the global thread pool.

To minimize the performance cost of creating new threads I thought it might be better to have a global thread pool. But then I wasn't certain what the best generic configuration would be so I punted and set the global thread pool to something that isn't actually a pool. I still like the idea, but I think my implementation (global variable) isn't very good. I'd like to find a better way to handle this.

One option we should consider is a global config block:

• http://robots.thoughtbot.com/mygem-configure-block
• https://github.com/sferik/twitter#configuration
• http://brandonhilkert.com/blog/ruby-gem-configuration-patterns/

[lucasallan]

• Actors updates ( https://github.com/jdantonio/concurrent-ruby-examples/issues/2 )
• Actors Persistence ( http://doc.akka.io/docs/akka/snapshot/scala/persistence.html )

[jdantonio]

I'm going to leave this open for a while to allow others to give input/feedback, but for now here's the plan for the 1.0 release (release date TBD):

• Updated Actor API
• Remote actors w/ pluggable transport layer
• Actor persistence
• Actor registry (maybe)
• Wrappers for Java's native thread pools
• Better gem configuration, specifically with respect to the global thread pool
• A fork/join framework based on (and optimized with) Java's fork/join framework
• Parallel enumerable (likely built on fork/join)
• Other abstractions based on (and optimized with) java.util.concurrent
• Software Transactional Memory

[chrisseaton]

I should complete the STM within a month - it works and is on a branch but needs lots of tuning. I'll also plan to look at fork-join and the JRuby support for that - plan have something working within the same time frame.

[jdantonio]

The roadmap is now in the wiki. Further discussion can occur there.