ruby-dev summary 25373-25479

[Masayoshi Takahashi]

Hi all,

This is a ruby-dev summary in these days.


[ruby-dev:25430] 1.8 warn nonblocking IO#read and add IO#readpartial

Akr suggested to make changes of IO in ruby 1.8:

* warn when you use nonblocking IO#read
* add a new method IO#readpartial

But Tomita raised an objection to add warning to 1.8 stable version
([ruby-dev:25443]). If correct scripts in 1.8.2 become "broken"
in 1.8.3, many users and developers will be confused and they think
that Ruby is not a stable language. However, mput pointed out that
Ruby change its specification in stable version (ex. between 1.8.1
and 1.8.2). Matz admitted that there are some (non-critical) incompatible
changes and some of them are on purpose.

Akr made a modified suggestion that warnings are raised with
-w option.



# ruby-dev summary index:
# http://i.loveruby.net/en/ruby-dev-summary.html

Regards,

Masayoshi 'Maki' Takahashi E-mail: (e-mail address removed)

 

[Florian Gross]

[ruby-dev:25430] 1.8 warn nonblocking IO#read and add IO#readpartial

Akr suggested to make changes of IO in ruby 1.8:

* warn when you use nonblocking IO#read
* add a new method IO#readpartial

Does anybody know what is wrong with these? Are they not working
correctly or will non-blocking IO be deprecated in general?

Thank you for the summary.

 

[Tim Sutherland]

[ruby-dev:25430] 1.8 warn nonblocking IO#read and add IO#readpartial

Akr suggested to make changes of IO in ruby 1.8:

* warn when you use nonblocking IO#read
* add a new method IO#readpartial

Does anybody know what is wrong with these? Are they not working
correctly or will non-blocking IO be deprecated in general?

Thank you for the summary.

See [ruby-talk:95953].

IO#read uses stdio which doesn't know about non-blocking, so data can be
lost. IO#sysread is a safe alternative if non-blocking IO is used.

The only place I'm aware of where non-blocking IO is useful in Ruby is for
sockets when calling accept().

(There's a race condition if we just rely on select() saying someone's
a-knockin': the client can leave between when select() returns and accept()
is called. If blocking sockets are used the call to accept() can then block
and no other threads can run. I'm not sure if the socket library actually does
deal with this...)

 

[Tanaka Akira]

Does anybody know what is wrong with these? Are they not working
correctly or will non-blocking IO be deprecated in general?

The non-blocking IO itself is not deprecated.
It may be useful to avoid whole process blocking.

 

[James Edward Gray II]

The only place I'm aware of where non-blocking IO is useful in Ruby is
for
sockets when calling accept().

I don't think that's the "only" place. There have been examples
posted to this list fairly recently that demonstrate when Ruby's
multicasting techniques are not enough. Non-Blocking IO remains a very
real option for high volume, high performance servers.

James Edward Gray II

 

[Bill Kelly]

I don't think that's the "only" place. There have been examples
posted to this list fairly recently that demonstrate when Ruby's
multicasting techniques are not enough.

Yes, I used to believe that the accept() race condition
was the only need for non-blocking IO in ruby. My mistaken
concepts of the behavior of the underlying syscalls were
corrected in:
http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/121573


Regards,

Bill

 

[Tanaka Akira]

IO#read uses stdio which doesn't know about non-blocking, so data can be
lost. IO#sysread is a safe alternative if non-blocking IO is used.

IO#read doesn't lost.
IO#write may lost. [ruby-talk:93917]

It is somewhat fixed in 1.8.2: nonblocking IO#write doesn't lost in
sync mode.

It is fixed in 1.9: nonblocking IO#write doesn't lost regardless of
sync mode.

So non-blocking flag is somewhat useful to avoid whole process
blocking in write, now.