Contributing to Concurrent Ruby

[Ian Ker-Seymer]

So, this semester I have an assignment for concurrent programming which is open ended. If possible, I would like to contribute to this library. 

Firstly, is there a roadmap for features/etc that need to be implemented? Are there any concurrency patterns which need to be covered which have not yet? I can devote significant time, and am an experienced Rubyist, but also comfortable with C/Java.

Anywho, I have to make a proposal very soon, so any response would be *incredibly* kind.

Hope to help the current state of concurrency in Ruby :)

Ian

[Jerry D'Antonio]

Ian,

We'd love to have your help working on the concurrent-ruby gem, or any of the gems in the ruby-concurrency organization. Below are a couple of thoughts, but I'm open to any suggestions you may have. Please feel free to open a GitHub issue if you would like to get feedback from the other team members. My email address is below if you would like to contact me directly. And if you don't mind me asking, what university do you attend? I'm just curious. This is the first open source project I started so I get very excited every time someone offers to help!

• There is a loose roadmap for 1.0 in GitHub Issue #142
• We've started tagging Issues with 0.9 and 1.0, any of those issues could be worked on
• Our test suite has many intermittently failing tests (Issue #117) that need updated
• Many of our tests use sleep calls rather than deterministic synchronization objects (Issue #225) and we'd love to refactor them
• We're putting in place a plan to merge the thread_safe gem into concurrent-ruby (Issue #230)
• We may need a lock-free cache for thread_safe (ruby-concurrency/thread_safe Issue #3)
• We're always open to suggestions for new abstractions to add, especially abstractions that exist in libraries from other languages (java.util.concurrent has been a great source of inspiration)

Anything on that list look interesting to you?

Best regards,

Jerry

--

Jerry D'Antonio

github.com/ruby-concurrency/concurrent-ruby

@jerrydantonio

--
You received this message because you are subscribed to the Google Groups "Concurrent Ruby" group.
To unsubscribe from this group and stop receiving emails from it, send an email to concurrent-ru...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jerry D'Antonio]

Ian,

To my knowledge, no one is working on a lock-free cache yet. That would be an awesome addition. We would love the help!

Best regards,

Jerry

On Fri, Apr 24, 2015 at 1:50 AM, Ian Ker-Seymer <i.ker...@gmail.com> wrote:

Has anyone begun on the concurrent lock-free cache yet? If not I would like to give this a go. I was planning on implementing a recursive split-ordered hash set for this. Does someone else think that another implementation may be better for this?

Cheers,

Ian

On Mon, Mar 2, 2015 at 2:10 PM, Petr Chalupa <chalu...@post.cz> wrote:

Also I forgot another idea: remote communication (also actors). The idea is to connect ruby processes similarly to what Erlang does. It would provide a way how to communicate between processes (with possibly different adapters: tcp, zeromq) which would then be used by abstractions where it makes sense: Actor, Channel, etc.

On Mon, Mar 2, 2015 at 2:28 PM, Petr Chalupa <chalu...@post.cz> wrote:

Hello Ian,

That's great news, any contributions are greatly appreciated. Few ideas:

- Agent implementation is incomplete at this moment, it does not behave fully as clojure's agent and it lacks STM integration

- STM could have interface so other abstractions can integrate: agents, actors, channels, etc. (message sending postponed to committing of the transaction)

- exploring of usage clojure's STM implementation on JRuby

Let us know if you would like to know more. You can also come and chat with us in https://gitter.im/ruby-concurrency/concurrent-ruby.

Petr

--

Cheers,

Ian

[Ian Ker-Seymer]

Awesome. Well I will get started on it this weekend. I plan on doing a pure Ruby version first, then I assume it would be best to build an MRI/Jruby backend afterwards. Is that right?

Also, are there any considerations for building c extensions for Rubinius? Or is it fully compatible with the MRI extension API?

[Ian Ker-Seymer]

Has anyone begun on the concurrent lock-free cache yet? If not I would like to give this a go. I was planning on implementing a recursive split-ordered hash set for this. Does someone else think that another implementation may be better for this?

Cheers,

Ian

On Mon, Mar 2, 2015 at 2:10 PM, Petr Chalupa <chalu...@post.cz> wrote:

Also I forgot another idea: remote communication (also actors). The idea is to connect ruby processes similarly to what Erlang does. It would provide a way how to communicate between processes (with possibly different adapters: tcp, zeromq) which would then be used by abstractions where it makes sense: Actor, Channel, etc.

On Mon, Mar 2, 2015 at 2:28 PM, Petr Chalupa <chalu...@post.cz> wrote:

Hello Ian,

That's great news, any contributions are greatly appreciated. Few ideas:

- Agent implementation is incomplete at this moment, it does not behave fully as clojure's agent and it lacks STM integration

- STM could have interface so other abstractions can integrate: agents, actors, channels, etc. (message sending postponed to committing of the transaction)

- exploring of usage clojure's STM implementation on JRuby

Let us know if you would like to know more. You can also come and chat with us in https://gitter.im/ruby-concurrency/concurrent-ruby.

Petr

On Fri, Feb 13, 2015 at 4:00 PM, Jerry D'Antonio <jerry.d...@gmail.com> wrote:

--

Cheers,

Ian

[Petr Chalupa]

It's best to use pure ruby version for rubinius. The C API on rubinius exist mostly for compatibility not performance AFAIK. What synchronization primitives does the algorithm need? Like:

- volatile fileds

- AtomicReference for CAS operations

- final fields (like Java final field)

If you take a look at the current `Synchronization::Object` it now provides only #synchronize, #wait, #signal, #condition nothing more. So if you need more let me know and I add those. I am planning to add what I've listed above anyway at some point.

Petr

[Petr Chalupa]

I've made progress with the synchronization layer in https://github.com/ruby-concurrency/concurrent-ruby/pull/284. If you don't mind, could you build the lock-free map using these tools?