distributed concurrent ruby

41 views
Skip to first unread message

lionel...@moodys.com

unread,
Jun 12, 2015, 11:21:58 AM6/12/15
to concurr...@googlegroups.com
Hello,

I plan to implement a first draft of a distributed concurrent ruby. I know that the major difficulty comes from the fact that concurrent ruby uses blocks for most API.

From my understanding of a good use of future, it seems that using closures is not fully satisfying since it allows futures to access external variables. I think that futures should rather be based on pure functions (without side effect). With this limitation, it becomes possible to serialize the function calls and thus permits a remote execution using drb for instance.

What do you think ? Do you foresee difficulties that will make this exploration pointless ?

Regards,

Lionel

Jerry D'Antonio

unread,
Jun 16, 2015, 4:56:25 PM6/16/15
to lionel...@moodys.com, concurr...@googlegroups.com
Lionel,

I apologize for not getting back to you sooner. I started a new job last week and had to go out of town. So I have been very busy.

I am definitely interested in adding distributed capabilities. We've talked about this for quite some time but haven't had an opportunity to execute. The approaches we have considered have been very different from what you are suggesting. We have always talked about remote actors and message passing. The idea you suggest sounds very interesting and certainly worth exploring. The main limitation with your approach is that it may not easily support a pluggable transport layer. That certainly isn't a problem, however. A simple DRb-based distributed future would be an awesome addition to the library,

Best regards,
Jerry


--
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.

lionel...@moodys.com

unread,
Jun 18, 2015, 3:23:54 AM6/18/15
to concurr...@googlegroups.com, jerry.d...@gmail.com
Thank your for your answer.
I'm understanding that using  remote actors and message passing is probably more promising. Nevertheless, I'll try to investigate further how futures/promises can be implemented as well. I'm still struggling to find an elegant way to declare pure functions. I need to make sure that these functions do not reference any global variable.
I'll let you know when I have something. 

Regards,

Lionel

lionel perrin

unread,
Oct 6, 2015, 9:53:30 AM10/6/15
to Concurrent Ruby, jerry.d...@gmail.com
Hello,

I've started a very first draft of implementation here: https://github.com/lionelperrin/concurrent-ruby-tcp.
I'd appreciate any feedback on this implementation. Especially, I'm looking for a way to move from this implementation to an implementation relying on an ExecutorService: something like a TCPExecutorService, similar to the ThreadExecutorService but limited to remote function execution.

Regards,

Lionel

Jerry D'Antonio

unread,
Oct 9, 2015, 9:16:31 AM10/9/15
to lionel perrin, Concurrent Ruby
Lionel,

Thank you very much for starting work on this! I've been very focused on RubyConf and the upcoming 1.0 release so I haven't had a chance to look at your repo yet. I will as soon as things slow down a little.

Best regards,
Jerry

Reply all
Reply to author
Forward
0 new messages