[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Thread and sleep

Tim Pease

12/15/2006 5:34:00 PM

$ 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
11 Answers

Ara.T.Howard

12/15/2006 6:04:00 PM

0

Tim Pease

12/15/2006 6:23:00 PM

0

On 12/15/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> 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

Ara.T.Howard

12/15/2006 7:25:00 PM

0

Kenosis

12/15/2006 7:43:00 PM

0


ara.t.howard@noaa.gov wrote:
> On Sat, 16 Dec 2006, Tim Pease wrote:
>
> > On 12/15/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> 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 :)
>
> throw an strace on the one-click and cyg-ruby and see. i'd be curious what's
> 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.

Kenosis

12/15/2006 7:45:00 PM

0


Kenosis wrote:
> ara.t.howard@noaa.gov wrote:
> > On Sat, 16 Dec 2006, Tim Pease wrote:
> >
> > > On 12/15/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> 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 :)
> >
> > throw an strace on the one-click and cyg-ruby and see. i'd be curious what's
> > 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.

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

Tim Pease

12/15/2006 8:10:00 PM

0

On 12/15/06, Kenosis <kenosis@gmail.com> wrote:
>
> ara.t.howard@noaa.gov wrote:
> > On Sat, 16 Dec 2006, Tim Pease wrote:
> >
> > > On 12/15/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> 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 :)
> >
> > throw an strace on the one-click and cyg-ruby and see. i'd be curious what's
> > 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.
>

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

12/15/2006 8:44:00 PM

0

On 12/15/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> On Sat, 16 Dec 2006, Tim Pease wrote:
>
> > On 12/15/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> 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 :)
>
> 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

12/15/2006 8:58:00 PM

0

Ara.T.Howard

12/15/2006 10:32:00 PM

0

Tim Pease

12/15/2006 11:57:00 PM

0

On 12/15/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> On Sat, 16 Dec 2006, Tim Pease 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