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
This is accurate, of course threads _may_ simplify your design, which
is a virtue as well.
pth
On 2/21/06, tony summerfelt <snowzone5@hotmail.com> wrote:
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
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.
On 2/21/06, tony summerfelt <snowzone5@hotmail.com> wrote:
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
--
-Dan Nugent
Dňa Utorok 21 Február 2006 19:10 Daniel Nugent 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 Vallner
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
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.
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
Daniel Nugent <nugend@gmail.com> 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.