"Mikael Brockman" <mikael / phubuh.org> schrieb im Newsbeitrag
news:87r7mgzo8x.fsf / igloo.phubuh.org...
> "Robert Klemme" <bob.news / gmx.net> writes:
>
> > "Mikael Brockman" <mikael / phubuh.org> schrieb im Newsbeitrag
> > news:87vfbszr5m.fsf / igloo.phubuh.org...
> >
> > > Blocking I/O is really easy to use.  But when you use it to write
> > > servers, you run into problems: you can't run two blocking syscalls
> > > simultaneously.  So if you're writing a huge file to some guy, every
> > > other client is stalled, and no one new can connect.  Unacceptable,
> > > for many types of servers.  They need non-blocking I/O.
> > >
> > > Non-blocking I/O is a lot more annoying to use.  Instead of going
> >
> > <snip/>
> >
> > > It'll run in one thread.  Multiplexer handles the select(3) calls.
> >
> > What is the advantage over a solution with threads?  IOW, why should I
> > use multiplexer over individual threads per connection?
>
> Since Ruby's threads aren't native, you can't do I/O from several at a
> time.

That's not true.

>  So one IO#read call blocking for a long time will block the other
> threads, too.

Also wrong: execute this script


tickers = [$stdout, $stderr].map do |io|
  Thread.new do
    100.times do |i|
      io.puts "#{io.fileno}: #{Time.now}: Tick #{i}"
      sleep 1
    end
  end
end

puts "PROMPT"
# blocks in next line:
input = gets
puts "ENTERED #{input}"

tickers.each {|th| th.join }

16:39:44 [ruby]: ruby ticker.rb
1: Fri Nov 26 17:40:05 GMT+2:00 2004: Tick 0
2: Fri Nov 26 17:40:05 GMT+2:00 2004: Tick 0
PROMPT
2: Fri Nov 26 17:40:06 GMT+2:00 2004: Tick 1
1: Fri Nov 26 17:40:06 GMT+2:00 2004: Tick 1
2: Fri Nov 26 17:40:07 GMT+2:00 2004: Tick 2
1: Fri Nov 26 17:40:07 GMT+2:00 2004: Tick 2
2: Fri Nov 26 17:40:08 GMT+2:00 2004: Tick 3
1: Fri Nov 26 17:40:08 GMT+2:00 2004: Tick 3
foo
ENTERED foo
2: Fri Nov 26 17:40:09 GMT+2:00 2004: Tick 4
1: Fri Nov 26 17:40:09 GMT+2:00 2004: Tick 4
2: Fri Nov 26 17:40:10 GMT+2:00 2004: Tick 5
1: Fri Nov 26 17:40:10 GMT+2:00 2004: Tick 5
2: Fri Nov 26 17:40:11 GMT+2:00 2004: Tick 6
1: Fri Nov 26 17:40:11 GMT+2:00 2004: Tick 6
2: Fri Nov 26 17:40:12 GMT+2:00 2004: Tick 7
1: Fri Nov 26 17:40:12 GMT+2:00 2004: Tick 7

>  You could loop a read with a time-out, I guess.  But with
> a single thread running select, the whole process can stall completely
> while waiting for I/O.  And it's more elegant.  :-)

IMHO threads are more elegant.

Regards

    robert