Hi,
Yes, I know, but what I said is the reverse. It blocks when you do supply
the maximum read size, not when you don’t.
I think I’m confusing. Let me check the source again…
OK. Now I understand my code better:
(a) IO#read (without size) returns all available data on the IO.
It doesn’t block if O_NONBLOCK is set. I was wrong in
[ruby-talk:66149].
(b) IO#read (with maximum size) raise an EWOULDBLOCK exception if the
buffer is empty. It returns the buffer contents if the buffer is
partially filled before EWOULDBLOCK.
I’m not sure you’re complaining to which behavior (or both).
matz.
···
In message “Re: Unable to do non-blocking read on socket” on 03/03/03, Seth Kurtzberg seth@cql.com writes:
Hi,
Yes, I know, but what I said is the reverse. It blocks when you do
supply the maximum read size, not when you don’t.
I think I’m confusing. Let me check the source again…
OK. Now I understand my code better:
(a) IO#read (without size) returns all available data on the IO.
It doesn’t block if O_NONBLOCK is set. I was wrong in
[ruby-talk:66149].
Not what I would like to see but not what I was trying to use.
(b) IO#read (with maximum size) raise an EWOULDBLOCK exception if the
buffer is empty. It returns the buffer contents if the buffer is
partially filled before EWOULDBLOCK.
It never returns EWOULDBLOCK. Unless the buffer is empty at the time of the
call, it blocks until the maximum number of bytes (as specified by the
parameter) is received.
So, both variations block, and NONBLOCK behavior is not available with either.
···
On Sunday 02 March 2003 11:16 am, Yukihiro Matsumoto wrote:
In message “Re: Unable to do non-blocking read on socket” > > on 03/03/03, Seth Kurtzberg seth@cql.com writes:
I’m not sure you’re complaining to which behavior (or both).
matz.
–
Seth Kurtzberg
M. I. S. Corp.
480-661-1849
seth@cql.com
Hi,
IO#read without maximum size is supposed to read all data from the
port, so that it should naturally block.
On EAGAIN io.c:read_all() exits with already read data
successfully, doesn’t it?
Perhaps, but as EAGAIN doesn’t occur in the problem situation, this doesn’t
help.
···
On Sunday 02 March 2003 11:19 am, Yukihiro Matsumoto wrote:
In message “Re: Unable to do non-blocking read on socket” > > on 03/03/03, nobu.nokada@softhome.net nobu.nokada@softhome.net writes:
Yes, I make mistakes sometimes, …ah, well…, often. X-<
matz.
–
Seth Kurtzberg
M. I. S. Corp.
480-661-1849
seth@cql.com
matz,
You won’t see the blocking behavior unless you are actually talking across the
net. It works fine on the same machine, but that isn’t terribly helpful.
My test case is talking to a machine over the internet; I’m testing to see if
this is necessary to see the behavior.
···
On Sunday 02 March 2003 12:16 pm, Yukihiro Matsumoto wrote:
Hi,
In message “Re: Unable to do non-blocking read on socket” > > on 03/03/03, Seth Kurtzberg seth@cql.com writes:
(a) IO#read (without size) returns all available data on the IO.
It doesn’t block if O_NONBLOCK is set. I was wrong in
[ruby-talk:66149].
Not what I would like to see but not what I was trying to use.
Could you describe “what you’d like to see”? I’m having (sort of)
hard time to understand you.
By the way, it somewhat different from the documentation:
---------------------------------------------------------------- IO#read
ios.read( [anInteger] ) → aString or nil
Reads at most anInteger bytes from the I/O stream, or to the end of
file if anInteger is omitted. Returns nil if called at end of file.
f = File.new("testfile")
f.read(16) #=> "This is line one"
what do you guys think about this behavior. Should it be fixed as
the document says, or should we update the document?
(b) IO#read (with maximum size) raise an EWOULDBLOCK exception if the
buffer is empty. It returns the buffer contents if the buffer is
partially filled before EWOULDBLOCK.
It never returns EWOULDBLOCK. Unless the buffer is empty at the time of
the call, it blocks until the maximum number of bytes (as specified by
the parameter) is received.
So, both variations block, and NONBLOCK behavior is not available with
either.
?
On my machine, ruby 1.8.0 (2003-02-28) [i686-linux], (a) doesn’t
block, since it returns as much as data available without blocking if
O_NONBLOCK is set. And (b) doesn’t block neither, since it either
raises the exception, or returns data available on the buffer.
(a) is proved by Nobu’s example [ruby-talk:66126].
(b) can be proved by replacing the line in the example
p s.nonblock {sleep WAIT; s.read}
by
s.nonblock {sleep WAIT; p s.read(40); p s.read(40)}
and try
% ruby client.rb foo 2
you’ll get
“hello,”
/tmp/client.rb:8:in read': Resource temporarily unavailable - "/tmp/foo" (Errno::EWOULDBLOCK) from /tmp/client.rb:8 from /tmp/client.rb:8:in nonblock’
from /tmp/client.rb:8
matz.
–
Seth Kurtzberg
M. I. S. Corp.
480-661-1849
seth@cql.com
Hi,
You won’t see the blocking behavior unless you are actually talking across the
net. It works fine on the same machine, but that isn’t terribly helpful.
So, you’re saying IO#read (thus underlying stdio) works differently
across the net, are you? Or did I make any mistake in stdio
programming?
In any case, I need more clue to help you. I couldn’t reproduce any
of your problems, probably due to difference in connection
environment.
matz.
···
In message “Re: Unable to do non-blocking read on socket” on 03/03/03, Seth Kurtzberg seth@cql.com writes: