Hi,

"pat zes" <jonnypichler / gmx.net> wrote in message
> the thing is - your code features several calls to the OS - the echo and
the
> ping commands

Well, in that case try this simple script:

# --------------------------------

th = []
3.times { |i|
    th << Thread.new(i) {
        sleep(1)
        puts "#{i} Start> " + `echo %TIME%`
        `ping -n 15 localhost`
        puts "#{i} Stop> " + `echo %TIME%`
        }
}

th.each {|t| t.join }

#--------------------------------

And if you open up TaskManager and look at the "Processes" tab sorted by
Image name,
you will see three ping processes actually running for a while. You (may)
get output  like this:

    1 Start>  2:24:04.84
    0 Start>  2:24:04.85
    2 Start>  2:24:04.86
    2 Stop>  2:24:19.27
    0 Stop>  2:24:19.29
    1 Stop>  2:24:19.28

Which is kind of what I expected with drb too.

> ruby threads are (i think) ruby-internal so if ruby does a call to the OS,
> ruby can't act (let another thread do it's work) until it gets control
back
> from the OS. so your original code really was multithreaded but it seemed
> linear for ruby threads are not really threads to the OS....

Please see Yohanes Santoso's response.

> quote from the rubybook of the pragmaticprogrammers on this matter:
> > And if some thread happens to make
> > a call to the operating system that takes
> > a long time to complete, all threads will
> > hang until the interpreter gets control back.

Hmmm... will have to ponder on that !

> i modified your code (replaced the OS-calls) - and it IS multithreaded as
> you will see when you try it.

<snip>

Yes, that works like i want it to.
> regards, patrick

Thanks, patrick.
-- shanko


> using ruby 1.6.8 (pragmaticprogrammer installer 168-8) on winXPpro

Could it be that we are trying it on different versions of Ruby.
Let me see what happens on 1.8.

P.S> Did you get the article I emailed you?