1.0 Roadmap

[jdantonio]

I'd like us to consider making our next release after 0.7 our 1.0 release. We've made significant gains over the spring and summer. We've deprecated a ton of my earlier experimental stuff, fixed many bugs, greatly improved the reliability of our test suite, merged ruby-atomic, created an automated build process for compiling platform-specific gems, and added an entirely new and feature-rich actor framework. That's an amazing amount of work. It seems to me that we've now implemented most of the "must have" items and are now looking mostly at optimizations, refactoring, and "nice to have" features. If everyone else agrees, then I think we can start planning a 1.0 release.

We've had previous discussions here and here but a lot has changed since then. Starting the discussion anew seems appropriate.

Thoughts?

We can use this issue to discuss specific features and updates for the eventual 1.0 release.

[jdantonio]

Things we may want to include in a 1.0 release:

• Automated performance tests: @chrisseaton has done some amazing performance testing (examples here and here). He has suggested that we create a suite of automated performance tests for this gem.
• New Promise: @dsisnero correctly noted that our Promise implementation has evolved to be very similar to our Future and has suggested we look to Scala for inspiration (here and here). I am comfortable with deprecating the existing promise implementation in the final 0.7.0 release and creating a new promise implementation in 1.0.

[chuckremes]

If you plan to implement a new Promise API, you should allow some time for it to stabilize. Once you go 1.0, the API should really be frozen (assuming you are following semantic versioning).

So, I’d recommend a 0.8 (or similar) to allow time for any new APIs to shake out before declaring 1.0.

On Aug 6, 2014, at 9:13 AM, jdantonio notifications@github.com wrote:

Things we may want to include in a 1.0 release:

Automated performance tests: @chrisseaton has done some amazing performance testing (examples here and here). He has suggested that we create a suite of automated performance tests for this gem.
New Promise: @dsisnero correctly noted that our Promise implementation has evolved to be very similar to our Future and has suggested we look to Scala for inspiration (here and here). I am comfortable with deprecating the existing promise implementation in the final 0.7.0 release and creating a new promise implementation in 1.0.
—
Reply to this email directly or view it on GitHub.

[chrisseaton]

I will recommit to having the fork-join stuff in over the next couple of weeks.

[pitr-ch]

other things to consider:

1. Clojure aligned agent implementation integrated with STM to by able to use clojures impl. on JRuby later for performance.
2. OOPish agents where sending symbol will lead in execution of agent's method with same name, something like predefined functions.
3. Remote actors and support for Akka's un/become.
4. Integration of concurrent-ruby parts. Possibly through channels: anything can send message to them already, but we need an effective way how to connect agents, actors, thread-pools to channels output.
5. IO integration. At least few examples how to read effective IO (files, sockets, connections) and distribute them to other abstractions. (I have one example in mind for actors, I'll should push it soon.)
6. Renaming global thread pools to indicate better that blocking and long tasks should never go to global task pool.
7. Fix termination of global pools held in configuration. E.g. it's terminated before test suite runs if the pools are used in test suite of other gem/app.
8. Create a World object and move any global stuff there. User would have explicitly load require 'concurrent/single_world' to get single global space for their convenience, otherwise worlds would need to be created manually. TL;DR i think we should avoid any global states in this kind of gem.

I think we are getting close too, but I would do 0.8 first. If that works out we can promote to 1.0 with just few bugfixes and freeze the API.

[chrisseaton]

We should be careful that the world object doesn't become something that tries to own too much or is too self-important. I like the fact at the moment that you can drop our features in and out of a program. I think we want to avoid a case where you have to create or init a global world object at the start of your program. I remember libraries like SDL or wxWidgets that always wanted to 'own' your program like that.

[pitr-ch]

@chrisseaton i see your point, we need to keep it simple to use. That's why I've also suggested to create a global world for convenience if user chooses to require it.

On the other hand forcing the global world always can be problematic in tests and when combining e.g. two rails engines where both were already using concurrent-ruby in different ways. Having an global objects bit me too many times already, so I try to use suggested pattern to keep flexibility.

# file:world.rb
class World
  attr_reader :configuration # or possibly merge configuration into World
  # etc.
end

# file:single_world.rb, needs to be required
WORLD = World.new

[chrisseaton]

I see the use case - multiple parts of an application all using concurrency in different ways. That does seem like good software engineering in general, but with concurrency things are different - you don't want two thread pools that each think they should create as many threads as there are cores. I think concurrency is just a global concern.

Even the name World strikes me as extremely framework-y. If it's there for configuration, it should be called something like that. I don't think it should also include pools, for the reason above. What else would be in it?

I think this suits your actor stuff well where the framework needs to own the program to an extent, but works less well for things like futures and dataflow where it's very much the program just adding a few extra method calls here and there.

[chrisseaton]

@jdantonio Regarding Scala promises - I think they're basically an IVar with more methods for chaining things onto their completion. I think this means it makes sense to make a Promise a subclass of IVar. In Scala I believe a Future is also a Promise. So we'd have IVar -> Promise -> Future.

All these terms a bit muddled between different implementations. Future is a particularly abused term - when it was first introduced the whole idea was that there wasn't a Future type - you just had the type it delivered and were unaware it was asynchronous.

Future[T] is a contradiction in terms!

[pitr-ch]

@chrisseaton the Future is usually also a Promis, but there could also be Future and Promise as two different companion objects. I'll submit prototype to help with the discussion.

[pitr-ch]

world: @chrisseaton hm I did not think about the two big pools issue. An user would need to reduce the sizes to be able to keep both because of different overflow policies for example or inject one pool to the second world.

What about: keeping the global thread pools but remove any configuration so they are always same in any application. If user needs custom configured thread-pool he can create other pool and use it as needed inserting it into his objects. This may be an unpopular step, but I think it makes sense to keep the global thread pools only for its specified usage and disallow reconfiguration for other purpose.

[jdantonio]

The reason I created a global thread pool was to keep the simple use cases as simple as possible. This blog post is the perfect example. A user creates a bunch of futures for a simple task. If we don't have a global thread pool then the program changes entirely. One option would be for each future to get its own thread, which would be very inefficient. Another option would be to require the every user to manually configure a thread pool any time they want to use the gem. This would be a huge barrier to adoption.

There are a couple of things that I like about the current setup:

• The simple use case remains simple
• Advanced users can reconfigure the global thread pool to suit their needs
• Advanced users can inject different executors into different objects for fine-grained control
• Because the global pools are encapsulated in Delay objects the global pools don't run unless used

One of my influences for the global thread pool was Clojure's agent which creates a single global pool for all agents. Unlike our current global thread pool, a user of Clojure's agents cannot reconfigure the pool.

I'm definitely willing to revisit the idea of a global thread pool and change the way we do things. But I think we do a disservice if we force our users to always manually configure the gem. I this we should try to provide a simple yet reasonably performant default that serves the need of users like the one in the previously linked blog post.

One other thing we need to consider is they type of application most likely to be written by our users. This is a Ruby library, not a Java or Scala library. I don't personally know any Ruby programmers who are writing processor-intensive applications. All of the Ruby programmers I know write IO-intensive applications. Limiting the global thread pool to one-thread-per-processor probably wouldn't be a very efficient approach. And it wouldn't help MRI users at all since MRI only uses one core.

I know that it's impossible to know in advance how our users are going to use this gem, but I think we can make some reasonable guesses given the domains Ruby is most commonly used in.

[lucasallan]

I think we might need a couple more releases before 1.0. As @chuckremes mentioned, we need to make sure that we have a well defined and final api before release 1.0.

[pitr-ch]

@jdantonio yeah i think in general we agree. I want to keep simplicity and flexibility too. I worry about the case of integrating two applications where each configures the global threads differently.

To improve that use case I think there are 2 ways.
First:

• The simple use case remains simple
• Advanced users can reconfigure the global thread pool to suit their needs
• Advanced users can inject different executors into different objects for fine-grained control
• Because the global pools are encapsulated in Delay objects the global pools don't run unless used

I think the 3. option is enough for the flexibility. If we agree on removing the configuration of global thread pools we could remove configuration and move the global pools directly under Concurrent module.

Second:
As previously suggested: Creation of world object holding pools and configuration (logging). A single global world would be provided for convenience.

I think we can go either way. Did I omit other options?

Btw what are your thoughts one the other points I wrote in #142 (comment)?