Thread and sleep

[Tim Pease]

$ cat a.rb

t = Thread.new do
while true
puts "printing a line"
sleep 2
end
end

gets
t.exit
puts "exiting"


$ ruby a.rb
printing a line
printing a line
printing a line
printing a line
exiting # after I hit the "Enter" key


This is how it works on Linux and on Cygwin. But when I run the same
code on Windows using the one-click installer ruby, this is what I get
...

ruby a.rb

printing a line

exiting # after I hit the "Enter" key


It does not matter how long I let the script run, I'm only getting the
message out of the thread once. It's like the thread never wakes up
again after it goes to sleep.

Is this normal / expected behavior on Windows? Am I missing something obvious?

Blessings,
TwP

 

[ara.t.howard]

$ cat a.rb

t = Thread.new do
while true
puts "printing a line"
sleep 2
end
end

gets
t.exit
puts "exiting"


$ ruby a.rb
printing a line
printing a line
printing a line
printing a line
exiting # after I hit the "Enter" key


This is how it works on Linux and on Cygwin. But when I run the same
code on Windows using the one-click installer ruby, this is what I get
...


printing a line

exiting # after I hit the "Enter" key


It does not matter how long I let the script run, I'm only getting the
message out of the thread once. It's like the thread never wakes up
again after it goes to sleep.

Is this normal / expected behavior on Windows? Am I missing something
obvious?

a) io and threads to not work together in the one-click installer

b) cygwin does

c) msys compiled ruby does

-a

 

[Tim Pease]

a) io and threads to not work together in the one-click installer

Curious about this one -- especially in light of (c) below. If the
msys compiler can get this right, why do the MS compilers break
threads like this? It makes no sense that all threads should get
stuck until an IO call gets handled :/

b) cygwin does

c) msys compiled ruby does

Thanks for the answer, though

TwP

 

[ara.t.howard]

Curious about this one -- especially in light of (c) below. If the
msys compiler can get this right, why do the MS compilers break
threads like this? It makes no sense that all threads should get
stuck until an IO call gets handled :/


Thanks for the answer, though

throw an strace on the one-click and cyg-ruby and see. i'd be curious what's
different.

-a

 

[Kenosis]

throw an strace on the one-click and cyg-ruby and see. i'd be curious what's
different.

-a

I had this problem on a project a couple of years back and the
conclusion of those who helped me from this group was that the io on
stdin was blocking all threads other threads while the thread with the
stdin io (gets) waited for input. I seem to recall someone saying that
this prevented two or more threads from trying to read from stdio at
the same time. Does this still ring true/correct? And the work around
as I recall was to use a windows system call to check for input being
ready before the thread tried to read from stdin so the others were
blocked as little as possible.

Ken

PS. I searched for that discussion here but I can't recall the user
name I had at the time and thus came up empty. Hope this helps some.

 

[Kenosis]

I had this problem on a project a couple of years back and the
conclusion of those who helped me from this group was that the io on
stdin was blocking all threads other threads while the thread with the
stdin io (gets) waited for input. I seem to recall someone saying that
this prevented two or more threads from trying to read from stdio at
the same time. Does this still ring true/correct? And the work around
as I recall was to use a windows system call to check for input being
ready before the thread tried to read from stdin so the others were
blocked as little as possible.

Ken

PS. I searched for that discussion here but I can't recall the user
name I had at the time and thus came up empty. Hope this helps some.

PPS. And this only occurred on Windoz, not *nix.

 

[Tim Pease]

I had this problem on a project a couple of years back and the
conclusion of those who helped me from this group was that the io on
stdin was blocking all threads other threads while the thread with the
stdin io (gets) waited for input. I seem to recall someone saying that
this prevented two or more threads from trying to read from stdio at
the same time. Does this still ring true/correct? And the work around
as I recall was to use a windows system call to check for input being
ready before the thread tried to read from stdin so the others were
blocked as little as possible.

Yeah, it does look like the "gets" is causing the other thread to not
wake up from sleep. This is really odd, though, since the other thread
is just sleeping and not trying to do any IO whatsoever. Hmmm ...
maybe the puts and the gets are not playing well together?

I use the gets line in little test applications to keep the thing
running until I hit enter. Then I do cleanup, etc. So it's nothing
mission critical, but it is very unexpected behavior. Possible bug?

Blessings,
TwP

 

[Tim Pease]

throw an strace on the one-click and cyg-ruby and see. i'd be curious what's
different.

Any suggestions for an strace equivalent on Windows? Let me rephrase
that, any suggestions for a "free" strace equivalent on Windows?

TwP

 

[ara.t.howard]

Yeah, it does look like the "gets" is causing the other thread to not
wake up from sleep. This is really odd, though, since the other thread
is just sleeping and not trying to do any IO whatsoever. Hmmm ...
maybe the puts and the gets are not playing well together?

I use the gets line in little test applications to keep the thing
running until I hit enter. Then I do cleanup, etc. So it's nothing
mission critical, but it is very unexpected behavior. Possible bug?

i bet it involves ruby's internal use of select for thread scheduling and
diffent input methods generated by mvc++ vs. msys being responsible for
dictating whether this blocks ruby or not.

-a

 

[ara.t.howard]

Any suggestions for an strace equivalent on Windows? Let me rephrase
that, any suggestions for a "free" strace equivalent on Windows?

sorry - i just assumed something like that would come with cygwin?

-a

 

[Tim Pease]

sorry - i just assumed something like that would come with cygwin?

strace works well in cygwin. Can't use it when launching the
one-click ruby, though. The one click is making calls outside the
cygwin sandbox, and that make strace cranky -- i.e. errors out when
trying to start the ruby process

There is (or was) a version for windows NT. It had some BSOD problems,
and I'm afraid to try it out on my XP box. Something about feeding
Windows after midnight or getting it wet -- can't remember exactly
what that old Tibetan monk warned me about.

TwP

 

[Joel VanderWerf]

strace works well in cygwin. Can't use it when launching the
one-click ruby, though. The one click is making calls outside the
cygwin sandbox, and that make strace cranky -- i.e. errors out when
trying to start the ruby process

There is (or was) a version for windows NT. It had some BSOD problems,
and I'm afraid to try it out on my XP box. Something about feeding
Windows after midnight or getting it wet -- can't remember exactly
what that old Tibetan monk warned me about.

Google for windbg and read its docs on logger.exe. (I've never used
them, so I may be completely wrong, but I think this is how you can
strace on windows.)