[comp.sys.hp] O_NDELAY doesn't seem to work on sockets in HP-UX 7.0

bergur@kerfi.hi.is (Bergur Thorisson) (08/24/90)

I am using sockets on an HP-9000/360 running hp-ux 7.0 and need reads to be
non-blocking which, for the life of me, does not seem to work.

After initializing the socket I use:
	if( (fcntl( s, F_GETFL, flag)) == -1 )
    		WriteErrLog("SiggiVar uti"); 
	else{
    		flag |= O_NDELAY;
    		if( (fcntl( s, F_SETFL, flag )) == -1 )
      			WriteErrLog("SiggiVar uti lengi"); 
	}

And then the read call looks like this:
      len = recv(s, buf, 16, 0);
But the read blocks.

Is there something I am getting wrong here or is this a bug and if so is there
a workaround.  HP has said 'gee I dunno know use select' but I don't 
find that an acceptable answer unless that is the only one.

Bergur Thorisson
Engineering Research Institute
Univerisity of Iceland -- Reykjavik

decot@hpisod2.HP.COM (Dave Decot) (08/25/90)

> I am using sockets on an HP-9000/360 running hp-ux 7.0 and need reads to be
> non-blocking which, for the life of me, does not seem to work.
> 
> After initializing the socket I use:
> 	if( (fcntl( s, F_GETFL, flag)) == -1 )
>     		WriteErrLog("SiggiVar uti"); 
> 	else{
>     		flag |= O_NDELAY;
>     		if( (fcntl( s, F_SETFL, flag )) == -1 )
>       			WriteErrLog("SiggiVar uti lengi"); 
> 	}

Part of the problem may be that when the F_GETFL operation is used,
the file status flags and access modes are returned in the return
value of the fcntl() function, and not placed in the flag argument.
See the RETURN VALUE section on the fcntl(2) manual page.

The third argument is not used for the F_GETFL operation at all, so this
code should be:

	flag = fcntl( s, F_GETFL, 0 ) | O_NDELAY;

	if( (fcntl( s, F_SETFL, flag )) == -1 )
	    WriteErrLog("SiggiVar uti lengi"); 

The documentation of the F_GETFL operation and the use of the third argument
is not so great; I will try to get it changed to explain this more clearly.

However, your original code above should have set the O_NDELAY flag
anyway, so that subsequent recv() calls do not block.  I will investigate
this apparent problem.

In the mean time, you may want to try the other two ways to get nonblocking
recv calls (FIOSNBIO and O_NONBLOCK), documented on the recv(2) man page.

Dave Decot
HP

Disclaimer: These are not official opinions or statements of HP, and they
are provided without warranty of any kind.