Hello Rodrigo,

Do you have a better use case for this?

Anuj


On 5 May 2011 21:53, Rodrigo Rosenfeld Rosas <rr.rosas / gmail.com> wrote:

>
> Issue #4649 has been updated by Rodrigo Rosenfeld Rosas.
>
>
> You're right Joel. Maybe the syntax I'm requesting to be included in
> standard Ruby should be something like:
>
> concurrently do
>  task {...}
>  ...
> end
>
> But, although the implementation is simple, having a standard idiom for
> that common requirement would be great. That means I wouldn't have to
> redefine this idiom not to rely on external gem while doing some
> scripting... Other than that, making it a language feature could allow some
> low level improvements in performance, but it is just a guess since I don't
> know how this could be achieved yet.
>
> Furthermore, depending on the specs, maybe it wouldn't be necessary to do
> something like "a, b = concurrently do...". Being a standard idiom, someone
> looking at a code like this would know for sure what is happening since it
> is a language feature instead of an external dependency...
>
> Also, my initial example was too simple, but I imagine possibly several
> variables inside each task that should be available at the end of the
> parallels/concurrently block.
> ----------------------------------------
> RubySpec #4649: Adding parallel constructors to Ruby 2.0
> http://redmine.ruby-lang.org/issues/4649
>
> Author: Rodrigo Rosenfeld Rosas
> Status: Open
> Priority: Normal
> Assignee: Yukihiro Matsumoto
> Category:
> Target version: 2.0
>
>
> I was not sure if this was RubySpec or Feature type.
>
> My request is to create some new syntax for easing the write of concurrent
> code with Ruby. The syntax could be something like this:
>
> parallels do
>  task "get response from service A" do # optional description
>    a = IO.read("http://serviceA/request")
>  end
>  task { b = get_response_from_service_b }
> end
>
> # at this point both tasks have finish, it's like a join in the threads at
> the end of the parallel block.
> call_another_service_that_depends_on(a and b)
>
> I am not sure, though, how to deal with scopes inside the parallel block.
> Traditionally in Ruby, this wouldn't work because both 'a' and 'b' would be
> local to the 'task' block and would not be accessible from the outside of
> the parallel block. If we don't want instance variables, I don't know what
> is the best approach for avoiding some "a=nil; b=nil" before the parallel
> block.
>
> Maybe this could start as a gem, but having it implemented directly in Ruby
> would be awesome, specially for scripts that usually don't rely in external
> dependencies for simplifying distribution...
>
> Any thoughts about this propose?
>
>
> --
> http://redmine.ruby-lang.org
>
>


-- 
Anuj DUTTA