Non-blocking socket still blocking!

[Joel Sherrill]

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