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 [1] 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 [2] it reads as only pushing as
many bytes into the transport as it says it can handle.


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.

Attachment: pgprHNmRNGs10.pgp
Description: PGP signature

Reply via email to