Forum: Ruby need for threads

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
tony summerfelt (Guest)
on 2006-02-21 20:00
(Received via mailing list)
a discussion of tcl threads came up in that newsgroup.

one of the posts stopped me cold. the msg boiled down to:

on a single non-ht cpu if your program can't do soemthnig while
waiting on a resource there's no real need for threaded code.

threading will actually slow down your program overall.

http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Patrick H. (Guest)
on 2006-02-21 20:09
(Received via mailing list)
On 2/21/06, tony summerfelt <removed_email_address@domain.invalid> wrote:
> telnet://ventedspleen.dyndns.org
>
>

This is accurate, of course threads _may_ simplify your design, which
is a virtue as well.

pth
Daniel N. (Guest)
on 2006-02-21 20:12
(Received via mailing list)
Uh, yeah, that's pretty much why not all code is threaded.

On the other hand, in programs above a certain size, or ones that have
graphical user interface, there usually is something else that you can
do while you're waiting on that resource.
David V. (Guest)
on 2006-02-22 02:27
(Received via mailing list)
DÅ?a Utorok 21 Február 2006 19:10 Daniel N. napísal:
> Uh, yeah, that's pretty much why not all code is threaded.
>
> On the other hand, in programs above a certain size, or ones that have
> graphical user interface, there usually is something else that you can
> do while you're waiting on that resource.
>

This is pretty much one of the few good reasons to use threads on a
single-core processor - to keep an interactive user interface
responsive. And
to give people that can't wrap their heads around parallel processing
headaches making them code Dining Philosophers *mutter*

They also make life simpler in some scenarios - it's definately easier
to make
a multithreaded application with parallel asynchronous input (think
packet
sniffing on multiple network interfaces) by hogging each with a thread
you
couldn't care less about if it blocks, than using standard asynchronous
IO,
which isn't even available for all input sources.

David V.
tony summerfelt (Guest)
on 2006-02-22 14:39
(Received via mailing list)
On Wed, 22 Feb 2006 03:09:22 +0900, you wrote:


>This is accurate, of course threads _may_ simplify your design, which
>is a virtue as well.

that's what i find. threading helps keep track of things that should
be happening at the same time. and who knows, maybe i'll have a
multi-cpu in the future :)
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Robert K. (Guest)
on 2006-02-22 14:51
(Received via mailing list)
Daniel N. <removed_email_address@domain.invalid> wrote:
> Uh, yeah, that's pretty much why not all code is threaded.
>
> On the other hand, in programs above a certain size, or ones that have
> graphical user interface, there usually is something else that you can
> do while you're waiting on that resource.

Like reading from or writing to another resource.  Exactly.  Ruby's
multithreading is only at a loss on a multi CPU machine with heavy
computation because it doesn't use more than one CPU.

Kind regards

    robert
This topic is locked and can not be replied to.