On Tue, Aug 28, 2012 at 6:11 PM, Andriy Andreyev <[email protected]> wrote:
> Sorry for jumping in, but Tony, can you please explain what the idea is
> behind having Threads implemented and not allowing them to be executed in
> parallel? Thanks in advance.
You can still get enough concurrent execution for a large class of
applications that way. This is true namely for applications which do
a lot IO. You can try it out yourself:
$ ruby19 -e '5.times.map {|t| Thread.new(t) {|id| 10.times {|i| printf
"th-%p: %5d\n",id,i}}}.each(&:join)'
th-0: 0
th-0: 1
th-1: 0
th-2: 0
th-0: 2
th-3: 0
th-0: 3
th-2: 1
th-4: 0
th-1: 1
th-2: 2
th-0: 4
th-3: 1
th-4: 1
th-2: 3
th-1: 2
th-3: 2
th-0: 5
th-4: 2
th-3: 3
th-1: 3
th-2: 4
th-4: 3
th-0: 6
th-3: 4
th-2: 5
th-1: 4
th-0: 7
th-4: 4
th-3: 5
th-1: 5
th-2: 6
th-0: 8
th-3: 6
th-4: 5
th-1: 6
th-0: 9
th-2: 7
th-3: 7
th-1: 7
th-4: 6
th-2: 8
th-1: 8
th-3: 8
th-2: 9
th-4: 7
th-1: 9
th-3: 9
th-4: 8
th-4: 9
Also, this approach allows to have multithreading on a platform which
does not support threads out of the box. Granted, these are rare
nowadays - that was more important in the early days.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
-- You received this message because you are subscribed to the Google Groups
ruby-talk-google group. To post to this group, send email to
[email protected]. To unsubscribe from this group, send email
to [email protected]. For more options, visit this
group at https://groups.google.com/d/forum/ruby-talk-google?hl=en
