Non-blocking socket still blocking!

Smith, Gene Gene.Smith at sea.siemens.com
Fri Sep 1 23:12:40 UTC 2000


Joel,
When both patches are applied, I no longer block in read()!  The only thing
I see wrong is that when I read back the flags with fctrl(F_GETFL) I see the
value 0x1002 even though 0x4002 was the value the flags were set to. Thanks
for the excellent help!

What is the alternate method of setting a socket non-blocking using ioctl
that you or Eric referred to?

Enjoy your 'za!

-Gene

> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at OARcorp.com]
> Sent: Friday, September 01, 2000 6:21 PM
> To: Eric Norum; Smith, Gene; rtems-users at OARcorp.com
> Subject: Re: Non-blocking socket still blocking!
> 
> 
> Eric Norum wrote:
> > 
> > Joel Sherrill wrote:
> > >
> > > Eric N read this carefully and see if I am on the money.
> > > [And no comments about the libio flags being a pain.  I
> > > know... the extra mapping causes nothing but trouble...
> > 
> > I guess that our messages must have crossed each other.
> > Your fix, which matches mine, is necessary, but not sufficient.
> > Something in the translation is failing to set 
> LIBIO_FLAGS_NO_DELAY in
> > the libio flags when O_NONBLOCK). is set in the fcntl 
> flags.  I don't
> > have time to look further.
> 
> Luckily, I was meeting the kids at Chuck E Cheez so was still here. 
> The other half of the puzzle is that the mapping between 
> LIBIO_FLAGS_NO_DELAY and O_NONBLOCK was not included in the
> association table in libio.c.  This now goes back to the
> question of correctness.  Are O_NONBLOCK and O_NDELAY equal?
> Should there be another LIBIO_FLAG?  My reading of the newlib
> code shows that O_NDELAY is BSD while O_NONBLOCK is POSIX so 
> I am leaning to the following being correct.
> 
> Gene.. I am pretty sure that the combination of these two
> will work for you.
> 
> cvs server: Diffing .
> Index: libio.c
> ===================================================================
> RCS file: /usr1/CVS/rtems/c/src/lib/libc/libio.c,v
> retrieving revision 1.31
> diff -u -r1.31 libio.c
> --- libio.c	2000/06/12 14:59:52	1.31
> +++ libio.c	2000/09/01 22:18:34
> @@ -109,6 +109,7 @@
>  
>  rtems_assoc_t status_flags_assoc[] = {
>    { "NO DELAY",  LIBIO_FLAGS_NO_DELAY,  O_NDELAY },
> +  { "NONBLOCK",  LIBIO_FLAGS_NO_DELAY,  O_NONBLOCK },
>    { "APPEND",    LIBIO_FLAGS_APPEND,    O_APPEND },
>    { "CREATE",    LIBIO_FLAGS_CREATE,    O_CREAT },
>    { 0, 0, 0 },
> 
> 
> 
> > > I think we introduced a minor glitch when we added the
> > > RTEMS filesystem infrastructure.  Gene.. follow this logic..
> > >
> > > You call fcntl() which sets things for the file descriptor
> > > in a generic sense.  And it seems to correctly get to
> > > rtems_bsdnet_fcntl().  But it checks for (iop->flags & 
> O_NONBLOCK).
> > > Unfortunately, the fcntl() routine mapped the bits into internal
> > > settings.  Since O_NONBLOCK is 0x4000 and LIBIO_FLAGS_NO_DELAY
> > > is 0x0001, the code fails to note that iop->flags has changed.
> > >
> > > So try this patch and let us all know.
> > >
> > > Index: rtems/rtems_syscall.c
> > > 
> ===================================================================
> > > RCS file: 
> /usr1/CVS/rtems/c/src/libnetworking/rtems/rtems_syscall.c,v
> > > retrieving revision 1.14
> > > diff -u -r1.14 rtems_syscall.c
> > > --- rtems/rtems_syscall.c       2000/06/12 15:00:08     1.14
> > > +++ rtems/rtems_syscall.c       2000/09/01 16:23:38
> > > @@ -730,7 +730,7 @@
> > >                         rtems_bsdnet_semaphore_release ();
> > >                         return EBADF;
> > >                 }
> > > -               if (iop->flags & O_NONBLOCK)
> > > +               if (iop->flags & LIBIO_FLAGS_NO_DELAY)
> > >                         so->so_state |= SS_NBIO;
> > >                 else
> > >                         so->so_state &= ~SS_NBIO;
> > >
> > > "Smith, Gene" wrote:
> > > >
> > > > I noticed that my read() on a supposedly non-blocking 
> socket still blocked
> > > > after
> > > > I had read all data from the socket and called read() 
> again.  I then checked
> > > >
> > > > the socket flags more closely to make sure I was really 
> setting it
> > > > non-blocking
> > > > (O_NONBLOCK is 0x4000) with the following code:
> > > >
> > > > /* set new_sock non-blocking */
> > > > flags = 0;
> > > > flags = fcntl( new_sock, F_GETFL, 0);
> > > > DTRACE(("\nOrig flags = 0x%x", flags));
> > > > flags = flags | O_NONBLOCK;
> > > > DTRACE(("\nflags|O_NON_BLOCK=0x%x", flags));
> > > > if ( fcntl( new_sock, F_SETFL, flags ) < 0)
> > > >         RTEMS_PANIC(("\nCan't set new_sock non-blocking"));
> > > > DTRACE(("\nflags set to 0x%x", flags));
> > > >
> > > > /* verify non-blocking flag set */
> > > > flags = 0;
> > > > flags = fcntl( new_sock, F_GETFL, 0);
> > > > if ( (flags & O_NONBLOCK) == 0 )
> > > >         DTRACE(("\nBad flags = 0x%x", flags));
> > > > else
> > > >         DTRACE(("\nGood flags = 0x%x", flags));
> > > >
> > > > The following output trace indicates that my attempt to 
> set the socket
> > > > non-blocking does not "stick."  (The value "new_sock" 
> is the return value
> > > > from
> > > > accept().) Any ideas why the socket seems to remain blocking?
> > > >
> > > > Orig flags = 0x2
> > > > flags|O_NON_BLOCK=0x4002
> > > > flags set to 0x4002
> > > > Bad flags = 0x2
> > > >
> > > > --Gene
> > >
> > > --
> > > Joel Sherrill, Ph.D.             Director of Research & 
> Development
> > > joel at OARcorp.com                 On-Line Applications Research
> > > Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> > >    Support Available             (256) 722-9985
> > 
> > --
> > Eric Norum                                 eric at cls.usask.ca
> > Canadian Light Source                      Phone: (306) 966-6308
> > University of Saskatchewan                 FAX:   (306) 966-6058
> > Saskatoon, Canada.
> 
> -- 
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985
> 



More information about the users mailing list