[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

ruby-dev summary 25373-25479

TAKAHASHI Masayoshi

1/20/2005 7:59:00 PM

6 Answers

Florian Gross

1/20/2005 10:02:00 PM

0

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.

timsuth

1/21/2005 10:57:00 AM

0

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.

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

1/21/2005 11:21:00 AM

0

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

James Gray

1/21/2005 2:42:00 PM

0

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

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

1/21/2005 5:32:00 PM

0

From: "James Edward Gray II" <james@grayproductions.net>
>
> 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().
>
> 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-t...


Regards,

Bill

Tanaka Akira

1/22/2005 1:44:00 AM

0

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