[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Threads and Ruby

barjunk

6/30/2008 4:44:00 AM

I've been hunting around for information regarding threads, and to me,
it seems confusing and conflicting.

What I'm trying to find out is...if I was going to start using threads
in Ruby, which version of Ruby should I be using.

I've seen folks say that I should use Ruby 1.9 and others say that it
is possible to use earlier versions. Nothing that I found seemed
definitive.

I'm new to all this, so this may be part of the problem.

What I'd like to accomplish is starting a main ruby instance, then
launch threads from that instance that run in their own sandbox.

At this point, I don't believe the threads need to talk with each
other, but it seems I could use some form of message passing to
accomplish this.

Any ideas and direction would be helpful. Thanks.

Mike B.
34 Answers

ara.t.howard

6/30/2008 5:00:00 AM

0


On Jun 29, 2008, at 10:44 PM, barjunk wrote:

> I've been hunting around for information regarding threads, and to me,
> it seems confusing and conflicting.
>
> What I'm trying to find out is...if I was going to start using threads
> in Ruby, which version of Ruby should I be using.
>
> I've seen folks say that I should use Ruby 1.9 and others say that it
> is possible to use earlier versions. Nothing that I found seemed
> definitive.
>
> I'm new to all this, so this may be part of the problem.
>
> What I'd like to accomplish is starting a main ruby instance, then
> launch threads from that instance that run in their own sandbox.
>
> At this point, I don't believe the threads need to talk with each
> other, but it seems I could use some form of message passing to
> accomplish this.
>
> Any ideas and direction would be helpful. Thanks.
>
> Mike B.

for any situation you want processes. use fork or systemu if you want
it portable. threads are not the way to get a sandbox.

cheers.

a @ http://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama

Joel VanderWerf

6/30/2008 5:04:00 AM

0

barjunk wrote:
> I've been hunting around for information regarding threads, and to me,
> it seems confusing and conflicting.
>
> What I'm trying to find out is...if I was going to start using threads
> in Ruby, which version of Ruby should I be using.
>
> I've seen folks say that I should use Ruby 1.9 and others say that it
> is possible to use earlier versions. Nothing that I found seemed
> definitive.
>
> I'm new to all this, so this may be part of the problem.
>
> What I'd like to accomplish is starting a main ruby instance, then
> launch threads from that instance that run in their own sandbox.
>
> At this point, I don't believe the threads need to talk with each
> other, but it seems I could use some form of message passing to
> accomplish this.
>
> Any ideas and direction would be helpful. Thanks.
>
> Mike B.

I haven't used 1.9 much, but the impression I get is:

- use 1.9 if you need _native_ threads (e.g. to take advantage of
multiple processors, or blocking system calls)

- use 1.8 if you want in-process threads, which are lighter and pretty
good for multiplexing io calls (using select()).

If the threads don't need shared state, why not use fork instead of
threads? You can use DRb for IPC.

--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

ara.t.howard

6/30/2008 5:06:00 AM

0


On Jun 29, 2008, at 11:00 PM, ara.t.howard wrote:

> for any situation you want processes. use fork or systemu if you
> want it portable. threads are not the way to get a sandbox.

*or* checkout the slave lib - it may be quite appropriate.

a @ http://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama

Charles Oliver Nutter

6/30/2008 9:14:00 AM

0

ara.t.howard wrote:
> for any situation you want processes. use fork or systemu if you want
> it portable. threads are not the way to get a sandbox.

I hope you mean "for this situation". Processes are definitely not the
solution to all problems.

- Charlie

Zhukov Pavel

6/30/2008 9:26:00 AM

0

On Mon, Jun 30, 2008 at 9:04 AM, Joel VanderWerf
<vjoel@path.berkeley.edu> wrote:
> barjunk wrote:
>>
>> I've been hunting around for information regarding threads, and to me,
>> it seems confusing and conflicting.
>>
>> What I'm trying to find out is...if I was going to start using threads
>> in Ruby, which version of Ruby should I be using.
>>
>> I've seen folks say that I should use Ruby 1.9 and others say that it
>> is possible to use earlier versions. Nothing that I found seemed
>> definitive.
>>
>> I'm new to all this, so this may be part of the problem.
>>
>> What I'd like to accomplish is starting a main ruby instance, then
>> launch threads from that instance that run in their own sandbox.
>>
>> At this point, I don't believe the threads need to talk with each
>> other, but it seems I could use some form of message passing to
>> accomplish this.
>>
>> Any ideas and direction would be helpful. Thanks.
>>
>> Mike B.
>
> I haven't used 1.9 much, but the impression I get is:
>
> - use 1.9 if you need _native_ threads (e.g. to take advantage of multiple
> processors, or blocking system calls)
>
> - use 1.8 if you want in-process threads, which are lighter and pretty good
> for multiplexing io calls (using select()).
>
> If the threads don't need shared state, why not use fork instead of threads?
> You can use DRb for IPC.
>
> --
> vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
>
>


really advantage on multiply processors? Ruby 1.9 does't use GIL???

Zhukov Pavel

6/30/2008 9:29:00 AM

0

On Mon, Jun 30, 2008 at 1:14 PM, Charles Oliver Nutter
<charles.nutter@sun.com> wrote:
> ara.t.howard wrote:
>>
>> for any situation you want processes. use fork or systemu if you want it
>> portable. threads are not the way to get a sandbox.
>
> I hope you mean "for this situation". Processes are definitely not the
> solution to all problems.
>
> - Charlie
>
>
Ruby doesn't have _real_ threads AFAIK, so DRb+fork it's the only way
to get true parallel work.

Robert Klemme

6/30/2008 11:10:00 AM

0

2008/6/30 barjunk <barjunk@attglobal.net>:
> I've been hunting around for information regarding threads, and to me,
> it seems confusing and conflicting.
>
> What I'm trying to find out is...if I was going to start using threads
> in Ruby, which version of Ruby should I be using.
>
> I've seen folks say that I should use Ruby 1.9 and others say that it
> is possible to use earlier versions. Nothing that I found seemed
> definitive.
>
> I'm new to all this, so this may be part of the problem.
>
> What I'd like to accomplish is starting a main ruby instance, then
> launch threads from that instance that run in their own sandbox.
>
> At this point, I don't believe the threads need to talk with each
> other, but it seems I could use some form of message passing to
> accomplish this.

As Ara said, in this case processes are the better choice for several
reasons: they have separation out of the box and they can make use of
multiple cores (which Ruby threads can't unless you use JRuby - this
may change with future 1.9 versions AFAIK).

Kind regards

robert

--
use.inject do |as, often| as.you_can - without end

Joel VanderWerf

6/30/2008 4:54:00 PM

0

Zhukov Pavel wrote:
> On Mon, Jun 30, 2008 at 9:04 AM, Joel VanderWerf
>> I haven't used 1.9 much, but the impression I get is:
>>
>> - use 1.9 if you need _native_ threads (e.g. to take advantage of multiple
>> processors, or blocking system calls)
> really advantage on multiply processors? Ruby 1.9 does't use GIL???

You're quite right.

--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

ara.t.howard

6/30/2008 5:20:00 PM

0


On Jun 30, 2008, at 3:14 AM, Charles Oliver Nutter wrote:

> I hope you mean "for this situation". Processes are definitely not
> the solution to all problems.

well, given that the difference between processes and threads is an
incredibly small one for any modern os, and given that threads are *at
least* 100 harder to write deterministic code for (as your bug reports
regarding exception handling and ruby illustrate) i'd hazard a guess
that processes are *almost* always the correct solution when robust
code is desired. in otherwords i'd take the position that one should
always use processes unless the reason becomes clear to use threads
and, of course ,there are indeed reasons. this is mostly a comment on
the limitations of programmers and not on platforms or languages,
nevertheless the incredible ease of IPC with ruby makes it even more
true imho.

cheers.

a @ http://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama

Iñaki Baz Castillo

6/30/2008 6:06:00 PM

0

El Lunes, 30 de Junio de 2008, Joel VanderWerf escribi=C3=B3:
> Zhukov Pavel wrote:
> > On Mon, Jun 30, 2008 at 9:04 AM, Joel VanderWerf
> >
> >> I haven't used 1.9 much, but the impression I get is:
> >>
> >> - use 1.9 if you need _native_ threads (e.g. to take advantage of
> >> multiple processors, or blocking system calls)
> >
> > really advantage on multiply processors? Ruby 1.9 does't use GIL???
>
> You're quite right.

A good article about it:
http://www.infoq.com/news/2007/05/ruby-threadi...

=2D-=20
I=C3=B1aki Baz Castillo