From: "Mauricio Fernández" Date: 2003-05-19T01:14:21+09:00 Subject: Re: select strange behavier On Sun, May 18, 2003 at 09:09:22PM +0900, Simon Strandgaard wrote: > On Sun, 18 May 2003 21:41:36 +0900, Marcin 'Qrczak' Kowalczyk wrote: > > > block not longer than a specific timeout. In ancient times without select the > > only option was busy waiting. > ^^^^^^^^^^^^ > > Busy waiting is what everyone wants to avoid.. > The same in my 'select' case, because of EOF notify then the thread > behaves exactly as if I were *busy waiting*. > > I don't want polling, I want blocking! > > Any suggestions to how I should get rid of this *busy waiting* ??? Essentially removing the IO object that got to EOF from the array of objects to be examined: (slight modification of the code you posted) batsman@tux-chan:/tmp$ expand -t2 aj.rb def system(command) r1, w1 = IO.pipe # stdout r2, w2 = IO.pipe # stderr fdes = [r1,r2] thread = Thread.new do loop do res = select(fdes, nil, nil, 0.1)[0] p res if res.include?(r1) unless r1.eof Redir.instance.write_out r1.read else fdes.delete r1 thread.kill if fdes == [] end end if res.include?(r2) unless r2.eof Redir.instance.write_error r2.read else fdes.delete r2 thread.kill if fdes == [] end end end end #sleep 0.3 # if we sleep then no output is captured, why ??? pid = fork do r1.close; r2.close $defout.reopen(w1); $stdout.reopen(w1); $stderr.reopen(w2) exec(command) # todo: should I care closing w1+w2 correctly? end w1.close; w2.close Process.waitpid(pid) # todo: Wait until the pipes r1+r2 is flushed completly sleep 0.5 r1.close; r2.close thread.kill end > > -- > Simon Strandgaard -- _ _ | |__ __ _| |_ ___ _ __ ___ __ _ _ __ | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \ | |_) | (_| | |_\__ \ | | | | | (_| | | | | |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_| Running Debian GNU/Linux Sid (unstable) batsman dot geo at yahoo dot com It's easy to get on the internet and forget you have a life -- Topic on #LinuxGER