From: Rudi Cilibrasi <cilibrar@...>
Date: 2007-10-04T08:14:29+09:00
Subject: Re: Non-blocking 'gets' ?

hmm, well the first-thread thing was really a guess.  i don't know
what else would
cause the different behvaior but perhaps there is another reason one
thread is privileged over another in terms of interactive terminal
ownership.  the only other thing i can think of is that somehow the
"interactive terminal" indication is switched around. maybe as a
result of the backtick or something?  i have also experienced strange
behavior with puts and gets but always chalked it up to one of the two
issues we've mentioned: buffering (with newline interactions) and
linked stdin-stdout file descriptor pairs.  i wish i had a simpler
explanation to offer but i suspect we are on the right track because
somebody else said something similar to what i did.  cheers, -r.

On 10/3/07, 7stud -- <dolgun@excite.com> wrote:
> Rudi Cilibrasi wrote:
> >
> > I would presume the "main"
> > (first) thread would be the only one able to take advantage of this
> > feature.  Does that make sense?
> >
>
> No, because if you look at the example I posted, the main thread has the
> statements:
>
> print "Enter command: "
> STDOUT.flush
> input = gets
>
> According to your explanation, the flush call should be unnecessary.
> --
> Posted via http://www.ruby-forum.com/.
>
>


-- 
"We can try to do it by breaking free of the mental prison of
separation and exclusion and see the world in its interconnectedness
and non-separability, allowing new alternatives to emerge." -- after
Vandana Shiva