$ 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
On Sat, 16 Dec 2006, Tim P. wrote:
t.exit
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
On 12/15/06, [email protected] [email protected] wrote:
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
[email protected] wrote:
stuck until an IO call gets handled 
different.
-a
if you find yourself slandering anybody, first imagine that your mouth is
filled with excrement. it will break you of the habit quickly enough. - the
dalai lama
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.
On 12/15/06, Kenosis [email protected] wrote:
msys compiler can get this right, why do the MS compilers break
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
On 12/15/06, [email protected] [email protected] wrote:
stuck until an IO call gets handled
different.
Any suggestions for an strace equivalent on Windows? Let me rephrase
that, any suggestions for a “free” strace equivalent on Windows?
TwP
On Sat, 16 Dec 2006, Tim P. wrote:
b) cygwin does
c) msys compiled ruby does
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
On Sat, 16 Dec 2006, Tim P. wrote:
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
On 12/15/06, [email protected] [email protected] wrote:
On Sat, 16 Dec 2006, Tim P. wrote:
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?
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
On Sat, 16 Dec 2006, Tim P. wrote:
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?
sorry - i just assumed something like that would come with cygwin?
-a
Tim P. wrote:
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.)