Hello!
I need help:
Is Ruby multithreading cooperative or preemptive?
I mean: am I forced to abuse of Thread.pass in (every heavy) threads or may I just assume the ruby interpreter will commute threads itself?
Another question:
Is Ruby multithreading blocked by system calls?
Like for example when calling system("command line").
If "no" to any of these questions, can I expect Ruby to work that way someday?
Thanks for the help,
Lionel Thiry
Hello!
I need help:
Is Ruby multithreading cooperative or preemptive?
Preemptive.
I mean: am I forced to abuse of Thread.pass in (every heavy) threads or may I just assume the ruby interpreter will commute threads itself?
Yes, ruby will handle thread scheduling.
Another question:
Is Ruby multithreading blocked by system calls?Like for example when calling system("command line").
Hmm, good question. I assume yes, but let's let someone who knows better than me answer this one... 
James Edward Gray II
On Dec 3, 2004, at 9:47 AM, Lionel Thiry wrote:
James Edward Gray II wrote:
Hello!
I need help:
Is Ruby multithreading cooperative or preemptive?Preemptive.
I mean: am I forced to abuse of Thread.pass in (every heavy) threads or may I just assume the ruby interpreter will commute threads itself?
Yes, ruby will handle thread scheduling.
Another question:
Is Ruby multithreading blocked by system calls?Like for example when calling system("command line").
Hmm, good question. I assume yes, but let's let someone who knows better than me answer this one...
Yes:
Thread.new {
loop do
sleep 1
p "."
end
}
system("sleep 10000")
And for IO operations, this is true, too. Ruby does not block on read/write as it internally uses select.
Regards,
Michael
On Dec 3, 2004, at 9:47 AM, Lionel Thiry wrote:
Michael Neumann wrote:
James Edward Gray II wrote:
Hello!
I need help:
Is Ruby multithreading cooperative or preemptive?Preemptive.
I mean: am I forced to abuse of Thread.pass in (every heavy) threads or may I just assume the ruby interpreter will commute threads itself?
Yes, ruby will handle thread scheduling.
Another question:
Is Ruby multithreading blocked by system calls?Like for example when calling system("command line").
Hmm, good question. I assume yes, but let's let someone who knows better than me answer this one...
Yes:
Thread.new {
loop do
sleep 1
p "."
end
}system("sleep 10000")
And for IO operations, this is true, too. Ruby does not block on read/write as it internally uses select.
Regards,
Michael
Thanks all,
Lionel
On Dec 3, 2004, at 9:47 AM, Lionel Thiry wrote:
No, system does not block other ruby threads.
$ cat x.rb
STDOUT.sync = true
Thread.new {
loop do
sleep 1
puts Time.now
end
}
system("sleep 10")
$ ruby -v x.rb
ruby 1.8.2 (2004-11-06) [powerpc-darwin7.6.0]
Fri Dec 03 09:57:47 PST 2004
Fri Dec 03 09:57:48 PST 2004
Fri Dec 03 09:57:49 PST 2004
Fri Dec 03 09:57:50 PST 2004
Fri Dec 03 09:57:51 PST 2004
Fri Dec 03 09:57:52 PST 2004
Fri Dec 03 09:57:53 PST 2004
Fri Dec 03 09:57:54 PST 2004
Fri Dec 03 09:57:55 PST 2004
$
On 03 Dec 2004, at 08:12, Michael Neumann wrote:
James Edward Gray II wrote:
On Dec 3, 2004, at 9:47 AM, Lionel Thiry wrote:
Hmm, good question. I assume yes, but let's let someone who knows better than me answer this one...Yes:
Thread.new {
loop do
sleep 1
p "."
end
}system("sleep 10000")
And for IO operations, this is true, too. Ruby does not block on read/write as it internally uses select.
No, system does not block other ruby threads.
Thanks for the remark... I was a bit confused about my interpretation of the answer, and I could not test system("sleep 10000") on my windows2k to see how it works.
$ cat x.rb
STDOUT.sync = true
I didn't know that stuff!
It's interesting, where is that documented?
Thread.new {
loop do
sleep 1
puts Time.now
end
}system("sleep 10")
$ ruby -v x.rb
ruby 1.8.2 (2004-11-06) [powerpc-darwin7.6.0]
Fri Dec 03 09:57:47 PST 2004
Fri Dec 03 09:57:48 PST 2004
Fri Dec 03 09:57:49 PST 2004
Fri Dec 03 09:57:50 PST 2004
Fri Dec 03 09:57:51 PST 2004
Fri Dec 03 09:57:52 PST 2004
Fri Dec 03 09:57:53 PST 2004
Fri Dec 03 09:57:54 PST 2004
Fri Dec 03 09:57:55 PST 2004
$
Thanks for the help,
Lionel Thiry
No, system does not block other ruby threads.
Thanks for the remark... I was a bit confused about my interpretation of the answer, and I could not test system("sleep 10000") on my windows2k to see how it works.
Maybe only on (some) windows builds it blocks? I no longer have a windows machine handy to test these things on.
$ cat x.rb
STDOUT.sync = trueI didn't know that stuff!
It's interesting, where is that documented?
ri has it:
$ ri IO#sync
---------------------------------------------------------------- IO#sync
ios.sync => true or false
On 04 Dec 2004, at 08:02, Lionel Thiry wrote:
------------------------------------------------------------------------
Returns the current ``sync mode'' of _ios_. When sync mode is true,
all output is immediately flushed to the underlying operating
system and is not buffered by Ruby internally. See also +IO#fsync+.
f = File.new("testfile")
f.sync #=> false
$ ri IO#sync=
--------------------------------------------------------------- IO#sync=
ios.sync = boolean => boolean
------------------------------------------------------------------------
Sets the ``sync mode'' to +true+ or +false+. When sync mode is
true, all output is immediately flushed to the underlying operating
system and is not buffered internally. Returns the new state. See
also +IO#fsync+.
f = File.new("testfile")
f.sync = true
_(produces no output)_
Eric Hodel wrote:
No, system does not block other ruby threads.
Thanks for the remark... I was a bit confused about my interpretation of the answer, and I could not test system("sleep 10000") on my windows2k to see how it works.
Maybe only on (some) windows builds it blocks? I no longer have a windows machine handy to test these things on.
I haven't correcly explained. On my w2k, the sleep command simply doesn't exists, then I couldn't test that ruby code. And I have no clue about a substitute.
$ cat x.rb
STDOUT.sync = trueI didn't know that stuff!
It's interesting, where is that documented?ri has it:
$ ri IO#sync
Oh yes! I forgot STDOUT was simply an IO object.
But why do we need it here?
Lionle Thiry
On 04 Dec 2004, at 08:02, Lionel Thiry wrote:
Eric Hodel wrote:
No, system does not block other ruby threads.
Thanks for the remark... I was a bit confused about my interpretation of the answer, and I could not test system("sleep 10000") on my windows2k to see how it works.
Maybe only on (some) windows builds it blocks? I no longer have a windows machine handy to test these things on.
I haven't correcly explained. On my w2k, the sleep command simply doesn't exists, then I couldn't test that ruby code. And I have no clue about a substitute.
Yes, I know.
$ cat x.rb
STDOUT.sync = trueI didn't know that stuff!
It's interesting, where is that documented?ri has it:
$ ri IO#syncOh yes! I forgot STDOUT was simply an IO object.
But why do we need it here?
To be explicit and to behave as expected when you run it on a machine with sleep. Without it, the OS may buffer the printing, and flush when the program exits (all 10 lines at once). This would give the appearance that system() blocked the Ruby thread.
On 06 Dec 2004, at 08:07, Lionel Thiry wrote:
On 04 Dec 2004, at 08:02, Lionel Thiry wrote: