[Spread-users] Is there a limit on total traffic sent by Spread?

[Jeremy Hylton]

>>>>> "HR" == Herbert Rubens <Herb at cnds.jhu.edu> writes:

  HR> The Sess_read() method in session.c is registered to be called
  HR> by the event system upon activity on a file descriptor.  The
  HR> event system is using select to determine whether there is at
  HR> least 1 byte available to be read or that an error has occurred.
  HR> Since the socket is non-blocking and it is in a select() call,
  HR> it should never return EWOULDBLOCK.

There is no guarantee that a recv() call on a non-blocking will
succeed just because select() says it is ready for reading.  The same
is true for send() and a socket ready for writing.  I believe the
cases where this guarantee does not hold, I suspect it is always some
internal resource issue that prevents the kernel from making the
call.  In these cases, the operation will succeed later.

We have a product (ZEO, http://www.zope.org/Products/ZEO) that uses
non-blocking sockets.  We've had a number of failures on heavily
loaded servers that were the result of assuming that a failure in
recv() were fatal (*).  We've had to fix ZEO to detect and ignore the
following errors:

    recv(): EWOULDBLOCK, EAGAIN, EINTR
    send(): EAGAIN, WOULDBLOCK, ENOBUFS, EINTR

I checked Stevens for more details about why these errors occur, but
there isn't any discussion.  His examples of non-blocking socket code,
however, treat these errors as non-fatal.

Jeremy

* There seems to be an analog between a socket and a Spread mbox.  If
  there is a fatal error on a socket, the socket isn't closed.  The
  client continues to get errors on it until the client closes it.  I
  think an mbox should be have the same way.  In other words, if a
  client is responsible for opening the resource, it should be
  responsible for closing it.