I am using the ‘rsolr’ library on ruby-1.9.3 (Windows 7 64 bits) to
access the BITNAMI/Apache/Solr stack running on my desktop. When adding
records to the index, I sometimes get the exception below (but the
addition is correct, and my code works OK) :
Exception `Errno::EWOULDBLOCK’ at
C:/Ruby193/lib/ruby/1.9.1/net/protocol.rb:141 … read would block
The culprit is :
def rbuf_fill # net/protocol.rb, line 139
begin
@rbuf << @io.read_nonblock(BUFSIZE) # line 141
rescue IO::WaitReadable
...
rescue IO::WaitWritable
...
end
end
which rescues IO::WaitReadable and IO::WaitWritable, but not
EWOULDBLOCK. I wonder whether I do something wrong (should I rescue it
?) or it is a weakness of the Net library (on Windows maybe ?).
_md
2013/4/5 Michel D. [email protected]:
def rbuf_fill # net/protocol.rb, line 139
EWOULDBLOCK. I wonder whether I do something wrong (should I rescue it
?) or it is a weakness of the Net library (on Windows maybe ?).
I’m not sure what happen.
However the expected mechanism is follows.
IO::WaitReadable and IO::WaitWritable are modules.
IO#read_nonblock should raise an exception, EWOULDBLOCK for example,
extended by
IO::WaitReadable or IO::WaitWritable.
So the rescue clauses should trap the exception.
Tanaka A. wrote in post #1104577:
I’m not sure what happen.
However the expected mechanism is follows.
IO::WaitReadable and IO::WaitWritable are modules.
IO#read_nonblock should raise an exception, EWOULDBLOCK for example,
extended by
IO::WaitReadable or IO::WaitWritable.
So the rescue clauses should trap the exception.
I found where the exception came from. My code was called inside a Qt
GUI, using the ‘qtbindings’ gem. I used a global $DEBUG constant, and
the exception was raised by a $DEBUG = true in my code. It desappeared
when I renamed $DEBUG to $Debug.
Actually, ‘qtbindings’ has a $DEBUG global, so the exception was raised
by ‘qtbindings’ and not by ‘rsolr’.
This solves my problem, but maybe the rescue part of net/protocol.rb is
not complete, as you say. I am not competent on that…
_md