[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
