Ruby-dev summary 25373-25479

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: maki@rubycolor.org

Masayoshi Takahashi wrote:

[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...)

···

In article <35ao47F4ifd7uU1@individual.net>, Florian Gross wrote:

Masayoshi Takahashi wrote:

[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.

In article <35ao47F4ifd7uU1@individual.net>,
  Florian Gross <flgr@ccan.de> writes:

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.

···

--
Tanaka Akira

I don't think that's the "only" place. :slight_smile: 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

···

On Jan 21, 2005, at 5:01 AM, Tim Sutherland wrote:

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

In article <slrncv1nv5.6mo.timsuth@europa.zone>,
  timsuth@ihug.co.nz (Tim Sutherland) writes:

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.

···

--
Tanaka Akira

> 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. :slight_smile: 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

···

From: "James Edward Gray II" <james@grayproductions.net>

On Jan 21, 2005, at 5:01 AM, Tim Sutherland wrote: