named pipe problem

coolbean nieters at copernicus.crd.ge.com
Wed Aug 30 23:15:35 AEST 1989


Hi

I have a question about named pipes and SunOS 3.5/4.0.3

The processes seem to block on a write()  after 20 ( 22 on SunOS 4.0.3)
named pipes are open()'ed.

The source file is 0.c:
-------
#include <sys/file.h>

main(argc, argv)
    int argc;
    char *argv[];
{
    int wfd, rfd;
    char string[80];
    char packet[13];

	/* something to write to the pipe */
    sprintf(packet, "thisis13chars");

	/* the write pipe name depends on the program name */
    sprintf(string, "/tmp/%s.write", argv[0]);
    if ((wfd = open(string, O_RDWR)) < 0)
        {
	perror("open");
        printf("%s: create the %s pipe first\n", argv[0], string);
	exit(1);
        }

	/* announce that we are writing */
    printf("%s: writing %s\n", argv[0], packet);
    if (write(wfd, packet, sizeof(packet)) != sizeof(packet))
        {
        perror("write");
        exit(1);
        }

	/* construct the read pipe name; again depends on the program name */
    sprintf(string, "/tmp/%s.read", argv[0]);
    if ((rfd = open(string, O_RDWR)) < 0)
        {
	perror("open");
        printf("%s: create the %s pipe first\n", argv[0], string);
	exit(1);
        }

	/* announce that we are reading; if we see this on the screen
	   we can assume that the write was successful */
    printf("%s: preparing to read packet\n", argv[0]);
	/* do a blocking read of the .read pipe here */
    if (read(rfd, packet, sizeof(packet)) != sizeof(packet))
        {
        perror("read");
        exit(1);
        }
	/* will never see this unless another program writes to this
	   pipe. */
    printf("%s: read from pipe fd %d; %s\n", argv[0], rfd, packet);
  }
------------
It is tested by the following commands:

Step 1 - create the pipes:
/etc/mknod /tmp/0.write p
/etc/mknod /tmp/0.read p
/etc/mknod /tmp/1.write p
/etc/mknod /tmp/1.read p
/etc/mknod /tmp/2.write p
/etc/mknod /tmp/2.read p
/etc/mknod /tmp/3.write p
/etc/mknod /tmp/3.read p
/etc/mknod /tmp/4.write p
/etc/mknod /tmp/4.read p
/etc/mknod /tmp/5.write p
/etc/mknod /tmp/5.read p
/etc/mknod /tmp/6.write p
/etc/mknod /tmp/6.read p
/etc/mknod /tmp/7.write p
/etc/mknod /tmp/7.read p
/etc/mknod /tmp/8.write p
/etc/mknod /tmp/8.read p
/etc/mknod /tmp/9.write p
/etc/mknod /tmp/9.read p
/etc/mknod /tmp/10.write p
/etc/mknod /tmp/10.read p
/etc/mknod /tmp/11.write p
/etc/mknod /tmp/11.read p

Step 2 - compile the above program, 0.c
	cc -o 0 0.c

Step 3, copy the executable file 0 to the files 1, 2, .... 11

Step 4 - Run each of the executables in the background

./0 &
./1 &



If the program runs correctly, you will see the printf message of
    printf("%s: writing %s\n", argv[0], packet);
followed by the printf message of 
    printf("%s: preparing to read packet\n", argv[0]);
after which the program will block indefinately on the read().

However, when the executable "10" (ie. the 11th one) is fired up,
I get the "writing" message, but not the "reading" one.  upon 
examining the running process using dbx (or similar debugger) i 
find that it is hanging in the actual write() system call.  
If i kill one of the (blocked on read()) initial 10 processes,
all of a sudden the 11th one frees up and prints the "reading"
message.  

What am i hitting?  Is it a kernel limit?  Is it specific to named
pipes?  Each process is opening two pipes as O_RDWR so I'm not
exceeding the per process limit of file descriptors, but is there
a shell limit of 20?  (I tried this in both sh and csh and 
getdtablesize(2) tells me i have 30 to work with.)  Why can i
successfully run the 11th process on Sun OS 4.0.3 but not a 12th?
If you try to run this and can run the 12th (or the "n'th") please
try to continue until you "break" it to see if there is a limit on
your system.

any help will be appreciated!

--ed
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ed Nieters		     INTERnet: nieters at crd.ge.com
GE Corporate R&D	     UUCPnet:  uunet!crd.ge.com!nieters	       
Schenectady, NY 12301	     BELLnet:  (518) 387-5187



More information about the Comp.unix.wizards mailing list