Very Computer

Quote:>Is it possible (correct?) for write() on a descriptor marked for
>non-blockion I/O to block anyway?  I've been having a problem
>in which any time I have more than a few open named pipes,
>write() seems to block even though the fd is set using O_NDELAY,
>and the buffer is not full.
>Sun's man page seems to suggest that write() should return -1
>with EWOULDBLOCK or EAGAIN instead of blocking.  What is it I
>did wrong in the program below:
> --------------------------------
>#include <sys/types.h>
>#include <fcntl.h>
>#include <errno.h>
>main()
>{
> int i,j,k,l,err;
> char buf[100];
> for (i=0;i<50;i++) {
>     sprintf(buf,"fifo%d",i);
>     j = mkfifo(buf,0777);          if (j<0) {perror("mkfifo");}
>     k = open(buf,O_RDONLY|O_NDELAY);   if (k<0) perror("open(RDONLY)");
>     l = open(buf,O_WRONLY|O_NDELAY);   if (l<0) perror("open(WRONLY)");
>     if (fcntl(l,F_SETFL,fcntl(l,F_GETFL,0)|O_NDELAY)<0) perror("fcntl");
>     err = write(l,buf,1);              if (err<0) perror("write");
>     err = read( k,buf,1);          if (err<0) perror("read");
>/*   close(l);  (see below) */
>     close(k);
>     printf("cool %d\n",i);
> }
> sleep(30);
>}
> --------------------------------
>Yes, I know that the close() statement is "incorrectly" commented
>out.  The idea is to simulate a number of different processes which
>all have a named pipe open for reading.  This was the simplest
>program I could think of that reproduces the problem.
>In case it matters, This is on a Sun sparc 2
> % showrev -a
> ***************  showrev version 1.15  *****************
> * Hostname: "grizzly"
> * Hostid: "7230209f"
> * Kernel Arch: "sun4m"
> * Application Arch: "sun4"
> * Kernel Revision:
>   4.1.3 (GENERIC) #3: Mon Jul 27 16:44:16 PDT 1992
> * Release: 4.1.3
>The problem doesn't seem to occur on a system running Solaris, so
>it might be an OS rather than a programming question.

Just a wild pointer, but it did happen to me. Maybe you need to use the
O_NONBLOCK rather than the O_NDELAY. I found systems where both are
defined, have different values and the doco is confused which one to use
when. Good luck.

        fcntl( port->fd_listen , F_SETFL , 0
#ifdef O_NONBLOCK
                | O_NONBLOCK
#endif
#ifdef O_NDELAY
                | O_NDELAY
#endif
#ifdef FNDELAY
                | FNDELAY
#endif
        );

Hope that helps.
--
Phil Howard KA9WGN        | "It is good to keep a gun for peaceful purposes,

"If I was able to fix it, | designer of the Avtomat Kalashnikova 1947, while
it must have been broken" | at the Dallas 1994 Shot Show, Wed 12 Jan 1994.

O_NDELAY was introduced in an earlier release of System V.  The main
problem with it was that it caused read() to return 0 for both the
no-data-available-at-the-moment condition and the end-of-file condition.
SVR4 supports O_NDELAY for backward compatibility, keeping this problem.
It should be avoided in new applications if possible.

4.3 BSD provided the FNDELAY flag for fcntl().  It avoided the above
problem by having read() return -1 while setting errno to EWOULDBLOCK
if no data is available at the moment.  It is also different in that
it affects the actual tty or socket rather than just how you access it
so *any* process accessing the same tty/socket is affected when you
use FNDELAY.

POSIX.1 standardizes things a bit with O_NONBLOCK.  It is set in the
file table entry for an open file so using it doesn't generally
affect other processes.  It has read() return -1 for no-data-now
so there is no ambiguity.  However, it sets errno to EAGAIN, not
EWOULDBLOCK (unless you have a system where these are defined to
be the same -- I think such systems exists, but I haven't checked).

O_NONBLOCK is suppported in SVR4 and 4.4BSD.  In 4.4BSD though,
O_NONBLOCK is just a synonym for FNDELAY (ie. O_NONBLOCK affects
the actual device/socket and sets errno to EWOULDBLOCK -- unless
this changed after the book was published, I haven't checked --
the book was written slightly before 4.4BSD was released).

This is more of a history lesson than a solution to your problem.
I would suggest using only O_NONBLOCK when possible.  It sounds
like it is broken on that Sun system, though.

Hope that helps.
Tye

     Nothing is obvious unless you are overlooking something.