while a loop will fix it, it would be really nice to understand how
we get EAGAIN when we think that there are bytes there...
rob
On Dec 7, 2007, at 4:55 PM, Sam Lang wrote:
I'm seeing recv on a socket in non-blocking mode returning EAGAIN
occasionally, even though epoll has just told us there's bytes
waiting. I guess that's why the call was initially a blocking
recv. I can add a loop around the non-blocking recv while it
returns EAGAIN, unless someone can think of a better work around.
-sam
On Oct 16, 2007, at 8:56 PM, Rob Ross wrote:
sounds good to me. -- rob
Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Tue, 16 Oct 2007 16:47 -0500:
Thanks Pete. Hopefully we've got all sockets in non-blocking
mode now. Incidentally, the blocking calls in sockio.c aren't
used anymore, and since brecv doesn't actually leave the socket
in the same state it started, I'm tempted to remove or
deprecate those blocking functions altogether.
Not used at all, so can just whack them out. No need to deprecate.
At least I highly doubt there are any out-of-tree users of these
private functions in bmi-tcp.
-- Pete
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
