I have created two child thread using main thread- child1 and child2.
Now child 2 has stopped along with main thread. They stopped executing
or proceeding. Only child 1 is proceeding. After child1 finishes..child2
starts, and then main. I want both child1 and child 2 run parallely, how
to achieve that? any pointers/suggestion?
--
Posted via http://www.ruby-forum.com/.
Normally they run in parallel - there are some limitations on MRI
though. What Ruby do you use and what do your threads do?
Kind regards
robert
On Tue, Aug 28, 2012 at 4:01 PM, ajay paswan <lists@ruby-forum.com> wrote:
I have created two child thread using main thread- child1 and child2.
Now child 2 has stopped along with main thread. They stopped executing
or proceeding. Only child 1 is proceeding. After child1 finishes..child2
starts, and then main. I want both child1 and child 2 run parallely, how
to achieve that? any pointers/suggestion?
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
Ruby version:
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
Am doing WEB GUI testing using watirweb.
--
Posted via http://www.ruby-forum.com/.
ajay paswan wrote in post #1073586:
IOnly child 1 is proceeding. After child1 finishes..child2
starts, and then main.
Use JRuby or IronRuby : they do not use Giant Lock ...
regards,
--
Posted via http://www.ruby-forum.com/\.
Thank you very much for replying quick!
Normally they run in parallel - there are some limitations on MRI
though.
MRI?
What Ruby do you use and what do your threads do?
Ruby version:
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
Am doing WEB GUI testing using watirweb.
--
Posted via http://www.ruby-forum.com/\.
This version of Ruby (also known as MRI, Matz Ruby Interpreter, and also
YARV, Yet Another Ruby VM) does not support parallel multithreading and
instead uses a Global Interpreter Lock (or Global VM Lock) which only
allows one thread to run at a time.
Many operations release the GIL, such as I/O and certain uses of
cryptographic primitives. However, if you'd truly like to do parallel
computation in Ruby, it's not possible on this version of Ruby.
You need to use a Ruby implementation without a GIL that supports
thread-level parallelism, such as JRuby or Rubinius.
On Tue, Aug 28, 2012 at 7:19 AM, ajay paswan <lists@ruby-forum.com> wrote:
Ruby version:
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
--
Tony Arcieri
Tony Arcieri wrote in post #1073605:
Ruby version:
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]This version of Ruby (also known as MRI, Matz Ruby Interpreter, and also
YARV, Yet Another Ruby VM) does not support parallel multithreading and
instead uses a Global Interpreter Lock (or Global VM Lock) which only
allows one thread to run at a time.Many operations release the GIL, such as I/O and certain uses of
cryptographic primitives. However, if you'd truly like to do parallel
computation in Ruby, it's not possible on this version of Ruby.
Could you tell me the version's which allow multithread parallelism?
and why did they decided to not include multithread parallelism? because
I think its a facility.. if I am not wrong? and with time technology
should give more facilities.. any specific reason.. really want to know.
You need to use a Ruby implementation without a GIL that supports
thread-level parallelism, such as JRuby or Rubinius.
Will I face any problem if I use JRuby or Rubinius.. any compatibility
issues?
On Tue, Aug 28, 2012 at 7:19 AM, ajay paswan <lists@ruby-forum.com> > wrote:
--
Posted via http://www.ruby-forum.com/\.
Hi All,
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.
Andriy
Apart from getting the above answers.. I would like to point out that:
If I do:
sudo update-alternatives --config ruby
1 ↵
[sudo] password for use:
There are 2 choices for the alternative ruby (providing /usr/bin/ruby).
Selection Path Priority Status
------------------------------------------------------------
0 /usr/bin/ruby1.8 50 auto mode
1 /usr/bin/ruby1.8 50 manual mode
* 2 /usr/bin/ruby1.9.1 10 manual mode
And even I select 1.8, it has the same problem.. I cannot run both
thread parallelly!
--
Posted via http://www.ruby-forum.com/.
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
On Tue, Aug 28, 2012 at 6:11 PM, Andriy Andreyev <andreev00@gmail.com> 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.
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
By mapping Ruby Threads onto native threads, several threads can be
executing system calls in parallel. When a thread wants to do a system call
in 1.9, it can explicitly release the GIL and allow other threads to run.
The previous version of MRI used green threads and had lots of slowness
surrounding I/O due to the fact that it could only make one system call at
a time. This was also a huge issue for things like database drivers.
On Tue, Aug 28, 2012 at 9:11 AM, Andriy Andreyev <andreev00@gmail.com>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.
--
Tony Arcieri
There are only four Ruby implementations that can run threads
concurrently (which is what you are looking for):
* JRuby - always has had concurrent threads because the JVM has
concurrent threads
* Rubinius - switched to concurrent threading a bit over a year ago
* MacRuby - switched to concurrent threading some years ago
* IronRuby - always has had concurrent threads because the .NET CLR
has concurrent threads
Of these, Rubinius is closest to "100%" compatible with regular Ruby,
since it also supports C extensions. JRuby arguable has the most
stable thread implementation, since it's the JVM's threads and they've
been parallel for over a decade. MacRuby only works on OS X. IronRuby
only works on .NET platforms, but I think it works ok on Mono.
You cannot get concurrent threads on any version or build of standard
Ruby ("C Ruby", "MRI", "MatzRuby") at this time. Pick something else.
- Charlie
On Tue, Aug 28, 2012 at 11:11 AM, ajay paswan <lists@ruby-forum.com> wrote:
And even I select 1.8, it has the same problem.. I cannot run both
thread parallelly!
kindly clear me .. my confusion over why people has stopped
multithreading in ruby?
and.. how to know which ruby supports multi threading?
--
Posted via http://www.ruby-forum.com/.
Robert Klemme писал 28.08.2012 21:31:
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.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.
It does not, at least not by itself. Ruby 1.9 requires a proper pthreads
implementation, which means that you must provide a scheduler anyway. Ruby 1.8
had green threads, which did work on threadless platforms, but having green
threads doesn't require one to abandon multicore support. For example, Erlang
has both.
On Tue, Aug 28, 2012 at 6:11 PM, Andriy Andreyev > <andreev00@gmail.com> wrote:
--
WBR, Peter Zotov.
I want to draw attention to my question again, sorry for asking some
other things.
ajay paswan wrote in post #1073608:
Apart from getting the above answers.. I would like to point out that:
If I do:sudo update-alternatives --config ruby
1 ↵
[sudo] password for use:
There are 2 choices for the alternative ruby (providing /usr/bin/ruby).Selection Path Priority Status
------------------------------------------------------------
0 /usr/bin/ruby1.8 50 auto mode
1 /usr/bin/ruby1.8 50 manual mode
* 2 /usr/bin/ruby1.9.1 10 manual modeAnd even I select 1.8, it has the same problem.. I cannot run both
thread parallelly!
--
Posted via http://www.ruby-forum.com/\.
kindly clear me .. my confusion over why people has stopped
multithreading in ruby?
Google is your friend
ruby gil
and.. how to know which ruby supports multi threading?
See Charlie's response above - clean list of implementations that support
concurrent threads.
On Tue, Aug 28, 2012 at 12:34 PM, ajay paswan <lists@ruby-forum.com> wrote:
A minor nit: depending on who you ask, the phrase "green threads" is the
proper opposite of "native threads". Systems that utilize native threads
for scheduling (e.g. the Erlang SMP scheduler) are probably not properly
described as "green threaded". Prior to the SMP scheduler, Erlang could be
described as green threaded.
Erlang's creators prefer the phrase "process" for its concurrency
primitive, although it can generally be described as being "microthreaded"
On Tue, Aug 28, 2012 at 1:00 PM, Peter Zotov <whitequark@whitequark.org>wrote:
Ruby 1.8 had green threads, which did work on threadless platforms, but
having green
threads doesn't require one to abandon multicore support. For example,
Erlang
has both.
--
Tony Arcieri
Try using RVM:
Once RVM has been installed, you can do:
rvm install jruby
or
rvm install rbx
On Tue, Aug 28, 2012 at 11:15 PM, ajay paswan <lists@ruby-forum.com> wrote:
I want to draw attention to my question again, sorry for asking some
other things.
--
Tony Arcieri
Tony Arcieri писал 29.08.2012 00:07:
Ruby 1.8 had green threads, which did work on threadless platforms, but
having green
threads doesn't require one to abandon multicore support. For example,
Erlang
has both.A minor nit: depending on who you ask, the phrase "green threads" is the
proper opposite of "native threads". Systems that utilize native threads
for scheduling (e.g. the Erlang SMP scheduler) are probably not properly
described as "green threaded". Prior to the SMP scheduler, Erlang could be
described as green threaded.Erlang's creators prefer the phrase "process" for its concurrency
primitive, although it can generally be described as being "microthreaded"
I think that the term "userspace threads" works for any protected-mode OS.
E.g DOS does not have explicitly defined userspace, but a scheduling
pthreads shim for DOS is effectively a green thread implementation, so the
distinction is a bit meaningless there.
"Interpreter-defined threads" would also cover various RTOS'es running in
environments where there is an OS/user code distinction, but no
userspace/kernelspace one, through it still does not work for DOS.
On Tue, Aug 28, 2012 at 1:00 PM, Peter Zotov > <whitequark@whitequark.org>wrote:
--
WBR, Peter Zotov.