From my perspective, which goes back to before I ever used Perl or iThreads, almost the last reason for using threads/concurrancy is performance.
The best reason is simplicity. It is just so much easier to code anything that takes a long time as a simple, linear subroutine, and then kick it off into a thread and let your main program get on with whatever else needs to be done.
The alternatives, like finite state machines are hard to code, and totally unportable even to the same OS on a faster processor. You take your slow, linear subroutine and break it into iddy-biddy chunks, carefully sized so that each one only takes as much time as you have available between doing the other things that need to be done, (like interacting with the user).
Move it to another, slower processor, (or just run another heavy process on the same machine), and your user interface is slow as molasses.
Move it to a faster machine and you either refactor all your stateful chunks into fewer, bigger chunks, or you waste half your cycles 'task switching' before it is necessary.
With threads, you write self contained, linear code, stick 'em in a thread and the scheduler takes care of everything else. The only time threads are a pain to debug is when people try to write them as a closed coupled state machine. Which is simply the wrong approach and easy to avoid.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Multitasking doesn't require threads, even on win32 AIUI (I appreciate it might not be as easy as on a real OS, but sucks to be you). Having another task in the same address space as you, but doing something unrelated is just a huge pain for no gain.
| [reply] |
I wouldn't use threads to run unrelated tasks in the same process. It's when the tasks are related and need to share data bi/multi-directionally that threads come into their own.
As for the gibes about "real OS", if you think that following the fad for white on black 24x80 screens, advisory locking and all the other artifacts from the 1970s makes you an uber-geek, you're welcome to them :)
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Threading is an obscure feature? What is this real world work you speak of? Or perhaps you do a different type of real world work than I. Undoubtedly so, threading is *important*.
Meanwhile, I concur that Ruby is very cool ... and spiffy threading support may come. Heck, I'm still hoping for Ruby-on-Parrot :)
| [reply] |
