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.
-sam On Oct 16, 2007, at 4:06 PM, Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Tue, 16 Oct 2007 16:54 -0400:Update of /projects/cvsroot/pvfs2/src/io/bmi/bmi_tcp In directory parlweb1:/tmp/cvs-serv25077/src/io/bmi/bmi_tcp Modified Files: bmi-tcp.c sockio.c Log Message:switching from the blocking receive (where we had just done a peek) to the non-blocking receive didn't work perfectly since new connections weren't getting set to nonblocking after accept (it looks like this is why blocking receive was used in the first place). The fix here sets the new socket to nonblocking and adds some asserts to make sure that sockets passed to nbpeek and nbrecv are nonblocking already. Thanks to Kevin for helping debug this one.I had run into this on another project previously, but missed what was going on with your bmi-tcp changes. The comment in this other projct was: fd = accept(...); [..] /** Explictly turn off nonblocking. Some OSes (Mac and perhaps its * BSD ancestors) inherit socket flags from the listening one to * the newly accepted one. Others (like linux) reset all F_GETFL * flags to default. This should be harmless even if O_NONBLOCK* was already turned off. */ flags = fcntl(fd, F_GETFL); if (flags < 0) error_errno("%s: get new socket flags", __func__); if (fcntl(fd, F_SETFL, flags & ~O_NONBLOCK) < 0) error_errno("%s: set new socket blocking", __func__); In my case I was relying on the "new socket is blocking" behavior of linux, erroneously. Just fyi. An obscure corner of undefined POSIX behavior. -- Pete
_______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
