From: Rudi Cilibrasi Date: 2007-10-04T07:55:26+09:00 Subject: Re: Non-blocking 'gets' ? > > On 10/3/07, 7stud -- wrote: > >> Stephen Ware wrote: > > your print doesn't print: it is not sending the return to cause the > > flush. But > > sending one yourself fixes it. The puts has the \n so the flush > > happens automatically I guess. > > Then why does this print command produce output without a call to flush: > > print "Enter data: " > line = gets > I would imagine because it is the interactive terminal (not backgrounded, probably first thread right?) and so the gets itself causes a flush of the associated file descriptor automatically. That is, stdin and stdout are linked in this way so that reading from stdin triggers a flush for stdout first. This happens in order to support prompting at interactive terminals, but obviously only one thread is supposed to read from stdin at the same time so only one is granted the special power of having a linked stdin / stdout. I think non-interactive output (not a tty) is not linked this way so you don't get extra convenient flushing for free. I would presume the "main" (first) thread would be the only one able to take advantage of this feature. Does that make sense? I would imagine the behavior is similar under windows also but I noticed there are sometimes differences. Like stdout and stderr are usually not different under windows. Cheers, -r. > > > -- > 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