[Pvfs2-developers] Re: [Pvfs2-cvs] commit by slang in pvfs2/src/io/bmi/bmi_tcp: bmi-tcp.c sockio.c

[Sam Lang]

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:

> cvs at parl.clemson.edu 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
>