This problem could be coming from a couple of different places. I notice
you are wrapping the collector and then trying to build your own plumbing
in ruby at the same time. I'd suggest you start by wrapping the Reactor
first. This will give you a smaller surface area to wrap in order to get to
working code, and once you are there you can build out any additional
plumbing you need in pure ruby (e.g. custom I/O handler for example). This
will both avoid building unnecessary plumbing and also be a bit easier to
debug since you can progress in one area at a time. As it is it's hard to
say if the bug is in the C code, the wrapper code, or the ruby I/O code.
On Thu, Feb 19, 2015 at 11:31 AM, Darryl L. Pierce <dpie...@redhat.com>
> So I'm hitting an interesting problem now with the work I'm doing on the
> Ruby engine APIs.
> I have both engine_send.rb and engine_recv.rb  examples written and
> working well. Today I changed them to be single-threaded applications,
> and that's when things got interesting.
> With a single threaded sender and receiver, the receiver hand handle
> messages up to a point (from about 2400 to 4800 messages) before blowing
> up with a EPIPE error.
> In debugging this I added a small piece of output to show the state of
> the sender. And suddenly the problem disappeared! I comment out the this
> piece of debugging and the problem comes back.
> Talking with a cube neighbor, I asked for a suggestion from him. His
> idea was to add a small sleep (0.0001s) at the spot where the debug line
> was executed in the code.
> Problem goes away.
> Change that to "sleep 0".
> Problem goes away.
> Comment the line out, and the problem comes back.
> So it's a very interesting issue. Adding the sleep 0 still involves a
> kernel call, so there's still even the smallest of delays there. But it
> seems that, for some reason, the code seems to be overrunning the
> outgoing buffer (first theory) and causing the connection to close.
> If you look at the selectable.rb class  it reads as only pushing as
> many bytes into the transport as it says it can handle.
> *LAST MINUTE EDIT*
> When turning on debugging in the send app (--debug, which just outputs
> a single line displaying an event when it occurs) is enough to keep the
> problem from occurring.
> It feels like this problem might be a buffer having a problem, though
> whether it's on the send or the receive side I'm not sure yet. The Ruby
> code is based on the Python code for handling reading and writing, and
> it asks the underlying Transport how many bytes can be written to it
> before trying to do so.
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.