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

[Tim Peters]

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

[Guido van Rossum]
> That would be true if there were a single recv() call in Sess_read().

Note that Jeremy believes EWOULDBLOCK (among others) is possible and
non-exceptional even in that case (and that ZEO has had to learn to tolerate
it).

OTOH, Sess_Read forces the socket to non-blocking for the recv(), but sets
it to blocking upon return, so it's not apparent to me that the select() is
done when the socket is in non-blocking mode.  If the socket is in blocking
mode when select() is done, EWOULDBLOCK on the *first* recv() would be more
surprising (to me) -- but not surprising on subsequent recv()'s.

> But there are two calls to recv() in that function, and the second one
> is in a loop that isn't satisfied until all expected bytes are read.

Not quite:  the loop is happy if it gets even one byte, regardless of how
many it expects (then it records as much as it saw, and returns).  In any
case, there's no select() guarding the recv() calls in the loop, so no
reason to consider EWOULDBLOCK exceptional for them.

> ...
> But I'm not seeing this on Windows -- I'm seeing it on Linux.  So
> please take it serious.  The code still looks broken to me, and that's
> the only explanation I have for the disconnects I see in our app.

Same here.

> (I can also easily trigger those disconnects with a little test program.)

Well, when people report Python bugs, they're mistaken so often that I take
them a lot more seriously when they come with a little test program.  So I
wouldn't be terribly surprised <wink> if our Spread friends would appreciate
seeing this test.