Buffered IO and UDPSocket

This one is driving me nuts! What causes and IO object (more
specifically a UDPSocket here, bound to port 1025) to become “buffered”?

When I do simple test case in irb with such a socket, I can call
#recvfrom on it with no problem. In my actual server, I get the error:
“`recvfrom’: recv for buffered IO (IOError)”. I can’t figure out why.

I payed attention that no threads are created, I do a select on this
socket (and others) to check for read readiness before calling
#recvfrom.

So what made the socket suddenly buffered so that #recv becomes illegal?
How can I check the buffered status of an IO? Can I revert it from
buffered to unbuffered?

It seems that I could get around this condition with #readpartial. But
this method is not avaible in 1.8.2. This code will need to run on
Windows and I rely on the one click installer…

Could someone shed some light on this “buffered” issue? It confuses the
hell out of me and the Google responses didn’t enlighten me.

Guillaume.

Guillaume M. [email protected] writes:

So what made the socket suddenly buffered so that #recv becomes
illegal? How can I check the buffered status of an IO? Can I revert it
from buffered to unbuffered?

You should not mix buffered methods (read, write, puts, etc.) with
unbuffered methods (sysread, syswrite, recv, recvfrom, etc)

Alternatively, you can use the nonstdio library which redefines the
various buffered methods in terms of unbuffered methods so you can mix
the two kinds of IO access.

Note, though, buffered IO is intrinsically blocking operations. It
does not play nice with multiplexor like Kernel#select.

YS.

I payed attention that no threads are created, I do a select on this
socket (and others) to check for read readiness before calling
#recvfrom.

I am having a problem similar to this. I have a reciever with a select
in it, which sees the incoming socket, but when I call socket.recv, I
get an error that says “in recv: recv for buffered IO”. I am using
threads in this program. Is that the problem, and if so, why, and how
do I recieve from a socket, inside a select, without having this
buffered problem?

Yohanes S. wrote:

Guillaume M. [email protected] writes:

So what made the socket suddenly buffered so that #recv becomes
illegal? How can I check the buffered status of an IO? Can I revert it
from buffered to unbuffered?

You should not mix buffered methods (read, write, puts, etc.) with
unbuffered methods (sysread, syswrite, recv, recvfrom, etc)

But I don’t. There is no call to any of read, write, puts, gets in the
entire app (except for some debugging on stdout with p).

Buffered and unbuffered calls cannot be mixed on a given IO object, but
they can be mixed in the same application, right?

Alternatively, you can use the nonstdio library which redefines the
various buffered methods in terms of unbuffered methods so you can mix
the two kinds of IO access.

The download links are broken on the web page.

Note, though, buffered IO is intrinsically blocking operations. It
does not play nice with multiplexor like Kernel#select.

I am trying to stayed unbuffered and use select. Don’t seem to be able
too. Or see why I suddenly switch to buffered.

Guillaume.