From owner-p4-projects@FreeBSD.ORG Mon Jun 15 07:16:21 2009 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 89C771065674; Mon, 15 Jun 2009 07:16:21 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47B391065676 for ; Mon, 15 Jun 2009 07:16:21 +0000 (UTC) (envelope-from zhaoshuai@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 336D98FC1A for ; Mon, 15 Jun 2009 07:16:21 +0000 (UTC) (envelope-from zhaoshuai@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.3/8.14.3) with ESMTP id n5F7GL7c096282 for ; Mon, 15 Jun 2009 07:16:21 GMT (envelope-from zhaoshuai@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id n5F7GLvD096280 for perforce@freebsd.org; Mon, 15 Jun 2009 07:16:21 GMT (envelope-from zhaoshuai@FreeBSD.org) Date: Mon, 15 Jun 2009 07:16:21 GMT Message-Id: <200906150716.n5F7GLvD096280@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to zhaoshuai@FreeBSD.org using -f From: Zhao Shuai To: Perforce Change Reviews Cc: Subject: PERFORCE change 164402 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 07:16:23 -0000 http://perforce.freebsd.org/chv.cgi?CH=164402 Change 164402 by zhaoshuai@zhaoshuai on 2009/06/15 07:16:16 add more PR testings Affected files ... .. //depot/projects/soc2009/fifo/fifo_test/functionality/Makefile#5 edit .. //depot/projects/soc2009/fifo/fifo_test/functionality/pr_116770.c#1 add .. //depot/projects/soc2009/fifo/fifo_test/functionality/pr_76525.c#2 edit .. //depot/projects/soc2009/fifo/fifo_test/functionality/pr_94772.c#1 add Differences ... ==== //depot/projects/soc2009/fifo/fifo_test/functionality/Makefile#5 (text+ko) ==== @@ -1,5 +1,6 @@ OBJS = rdwr reader1 reader2 writer1 bidirection1 bidirection2 select \ - poll pr_74242_speak pr_74242_tick pr_76144 + poll pr_74242_speak pr_74242_tick pr_76144 pr_94772 pr_116770 \ + pr_76525 all : $(OBJS) @@ -14,6 +15,9 @@ pr_74242_speak : pr_74242_speak.c pr_74242_tick : pr_74242_tick.c pr_76144 : pr_76144.c +pr_94772 : pr_94772.c +pr_116770 : pr_116770.c +pr_76525 : pr_76525.c clean : -rm $(OBJS) ==== //depot/projects/soc2009/fifo/fifo_test/functionality/pr_76525.c#2 (text+ko) ==== @@ -1,19 +1,23 @@ +/* Hi Danny, -Well, it only took me 8 hours, but I found the problem with the latest version of [Free]BSD. -I tracked down several false leads before I got on the right track -- it's only named FIFO's -that seem to exhibit this problem. I depend on them for the -P and -PP option of rtrace, which -is needed for memory sharing as I've set it up in Radiance. I don't think named FIFO's are used -very often, which might explain why this has gone undetected (or at least unfixed). +Well, it only took me 8 hours, but I found the problem with the latest version +of [Free]BSD. I tracked down several false leads before I got on the right +track -- it's only named FIFO's that seem to exhibit this problem. I depend +on them for the -P and -PP option of rtrace, which is needed for memory sharing +as I've set it up in Radiance. I don't think named FIFO's are used very often, +which might explain why this has gone undetected (or at least unfixed). -There are two test programs that demonstrate the problem. The first is called pipe.c, and on OS X, it produces the following (correct) output: +There are two test programs that demonstrate the problem. The first is called +pipe.c, and on OS X, it produces the following (correct) output: pipe available for read Read 4 bytes from pipe: 'TEST' pipe available for read Read 0 bytes from pipe: '' -Under FreeBSD 5.3, for some reason I get an exception condition on my pipe every time, which is strange but not fatal: +Under FreeBSD 5.3, for some reason I get an exception condition on my pipe every +time, which is strange but not fatal: Exception on pipe pipe available for read @@ -30,7 +34,8 @@ pipe available for read Read 0 bytes from pipe: '' -The real trouble begins with the second FIFO test in fifo.c. Under OS X, I get the correct output: +The real trouble begins with the second FIFO test in fifo.c. Under OS X, +I get the correct output: FIFO available for read Read 4 bytes from FIFO: 'TEST' @@ -50,24 +55,30 @@ Read 4 bytes from FIFO: 'TEST' (process hangs in second call to select) -Keep in mind that there should be no difference in the behavior between a named FIFO and a pipe -- the only difference is how they are mechanically connected by the two processes. Having the select() call hang when an EOF condition exists is not acceptable. +Keep in mind that there should be no difference in the behavior between a named +FIFO and a pipe -- the only difference is how they are mechanically connected by +the two processes. Having the select() call hang when an EOF condition exists is +not acceptable. I hope you can forward this to the appropriate FreeBSD gurus. Thanks, -Greg + How-To-Repeat: -source code for test programs described above: + source code for test programs described above: -... pipe.c: ... +*/ /* +* ... pipe.c: ... * Check pipe behavior * * Greg Ward * Compare also fifo.c */ +/* #include #include #include @@ -77,56 +88,53 @@ look(int fd) { -fd_set readfds, excepfds; + fd_set readfds, excepfds; -FD_ZERO(&readfds); -FD_ZERO(&excepfds); -FD_SET(fd, &readfds); -FD_SET(fd, &excepfds); -if (select(fd+1, &readfds, NULL, &excepfds, NULL) < 0) { -perror("select"); -exit(1); -} -if (FD_ISSET(fd, &excepfds)) -puts("Exception on pipe"); -if (FD_ISSET(fd, &readfds)) -puts("pipe available for read"); + FD_ZERO(&readfds); + FD_ZERO(&excepfds); + FD_SET(fd, &readfds); + FD_SET(fd, &excepfds); + if (select(fd+1, &readfds, NULL, &excepfds, NULL) < 0) { + perror("select"); + exit(1); + } + if (FD_ISSET(fd, &excepfds)) + puts("Exception on pipe"); + if (FD_ISSET(fd, &readfds)) + puts("pipe available for read"); } -void -spit(int fd) +void spit(int fd) { -char buf[512]; -int n = read(fd, buf, sizeof(buf)); -buf[n] = '\0'; -printf("Read %d bytes from pipe: '%s'\n", n, buf); + char buf[512]; + int n = read(fd, buf, sizeof(buf)); + buf[n] = '\0'; + printf("Read %d bytes from pipe: '%s'\n", n, buf); } main() { -int pp[2]; + int pp[2]; -pipe(pp); -if (fork() == 0) { -close(pp[0]); -write(pp[1], "TEST", 4); -close(pp[1]); -_exit(0); + pipe(pp); + if (fork() == 0) { + close(pp[0]); + write(pp[1], "TEST", 4); + close(pp[1]); + _exit(0); + } + close(pp[1]); + look(pp[0]); + spit(pp[0]); + look(pp[0]); + spit(pp[0]); + return(0); } -close(pp[1]); -look(pp[0]); -spit(pp[0]); -look(pp[0]); -spit(pp[0]); -return(0); -} - - -..fifo.c:... +*/ - /* +* ... fifo.c ... * Reproduce bug in FreeBSD 5.3-STABLE * * Greg Ward @@ -145,55 +153,60 @@ void look(int fd) { -fd_set readfds, excepfds; + fd_set readfds, excepfds; -FD_ZERO(&readfds); -FD_ZERO(&excepfds); -FD_SET(fd, &readfds); -FD_SET(fd, &excepfds); -if (select(fd+1, &readfds, NULL, &excepfds, NULL) < 0) { -perror("select"); -exit(1); + FD_ZERO(&readfds); + FD_ZERO(&excepfds); + FD_SET(fd, &readfds); + FD_SET(fd, &excepfds); + if (select(fd+1, &readfds, NULL, &excepfds, NULL) < 0) { + perror("select"); + exit(1); + } + if (FD_ISSET(fd, &excepfds)) + puts("Exception on FIFO"); + if (FD_ISSET(fd, &readfds)) + puts("FIFO available for read"); } -if (FD_ISSET(fd, &excepfds)) -puts("Exception on FIFO"); -if (FD_ISSET(fd, &readfds)) -puts("FIFO available for read"); -} void spit(int fd) { -char buf[512]; -int n = read(fd, buf, sizeof(buf)); -buf[n] = '\0'; -printf("Read %d bytes from FIFO: '%s'\n", n, buf); + char buf[512]; + int n = read(fd, buf, sizeof(buf)); + buf[n] = '\0'; + printf("Read %d bytes from FIFO: '%s'\n", n, buf); } main() { -int fifo_fd; + int fifo_fd; -unlink(FIFO); -mkfifo(FIFO, 0666); -if (fork() == 0) { -fifo_fd = open(FIFO, O_WRONLY); -write(fifo_fd, "TEST", 4); -close(fifo_fd); -_exit(0); -} -fifo_fd = open(FIFO, O_RDONLY); -look(fifo_fd); -spit(fifo_fd); -look(fifo_fd); -spit(fifo_fd); -return(0); + unlink(FIFO); + mkfifo(FIFO, 0666); + if (fork() == 0) { + fifo_fd = open(FIFO, O_WRONLY); + write(fifo_fd, "TEST", 4); + close(fifo_fd); + _exit(0); + } + fifo_fd = open(FIFO, O_RDONLY); + look(fifo_fd); + spit(fifo_fd); + look(fifo_fd); + spit(fifo_fd); + return(0); } +/* ..END... - -> Well, it only took me 8 hours, but I found the problem with the latest version of [Free]BSD. I tracked down several false leads before I got on the right track -- it's only named FIFO's that seem to exhibit this problem. I depend on them for the -P and -PP option of rtrace, which is needed for memory sharing as I've set it up in Radiance. I don't think named FIFO's are used very often, which might explain why this has gone undetected (or at least unfixed). +> Well, it only took me 8 hours, but I found the problem with the latest version +>of [Free]BSD. I tracked down several false leads before I got on the right track +>-- it's only named FIFO's that seem to exhibit this problem. I depend on them for +>the -P and -PP option of rtrace, which is needed for memory sharing as I've set +>it up in Radiance. I don't think named FIFO's are used very often, which might +>explain why this has gone undetected (or at least unfixed). Please limit line lengths to considerably less than 463 characters. @@ -248,7 +261,8 @@ (7) 3 years later, some PRs about (6) were filed. FIFOs are apparently still not often used. -> There are two test programs that demonstrate the problem. The first is called pipe.c, and on OS X, it produces the following (correct) output: +> There are two test programs that demonstrate the problem. The first is called +> pipe.c, and on OS X, it produces the following (correct) output: > > pipe available for read > Read 4 bytes from pipe: 'TEST' @@ -261,7 +275,8 @@ initially and writers don't come back after they are closed, so things are simpler. -> Under FreeBSD 5.3, for some reason I get an exception condition on my pipe every time, which is strange but not fatal: +> Under FreeBSD 5.3, for some reason I get an exception condition on my pipe +> every time, which is strange but not fatal: > > Exception on pipe > pipe available for read @@ -320,7 +335,10 @@ This is because not just POLLHUP for hangup is broken; not blocking for hangup is broken too. -> Keep in mind that there should be no difference in the behavior between a named FIFO and a pipe -- the only difference is how they are mechanically connected by the two processes. Having the select() call hang when an EOF condition exists is not acceptable. +> Keep in mind that there should be no difference in the behavior between a named +> FIFO and a pipe -- the only difference is how they are mechanically connected +> by the two processes. Having the select() call hang when an EOF condition exists +> is not acceptable. I agree for select(), but this is nonstandard for the EOF that occurs when there is no writer && no data && no hangup, and for poll() the @@ -396,58 +414,29 @@ the fixes of 1.40 were restored but select() on fifo was made to block waiting for a writer to appear. Also, a new event bitmask, POLLINIGNEOF for poll() has been - implemented. If the users want non-blocking behavior when there is no writer, they can call poll() instead, setting the event bitmask POLLINIGNEOF. To illustrate, we have implemented this change in the bug author's test program. We also believe that the current 5.x behavior is consistent - with the POSIX.1 standard as well as the overall intent of select(), but we are aware that this interpretation is not universally shared. -If the current behavior of select() on fifo, + +If the current behavior of select() on fifo,is not desirable, +the following patch can be applied to filo_poll() in fifo_vnops.c, +which reverses the select() behavior for fifo by reverting it to +non-blocking. Users need to set the event bitmask POLLINIGNEOF to +get blocking behavior. -is not desirable, the following patch can be applied to -filo_poll() in fifo_vnops.c, which reverses the select() -behavior for fifo by reverting it to non-blocking.Users -need to set the event bitmask POLLINIGNEOF to get blocking -behavior. While offering the change, we would like to reiterate - that we believe the change is inappropriate (inconsistent with POSIX.1) and should not be captured into CVS. ---- fifo_vnops_orig.c Wed Mar 16 16:13:24 2005 - -+++ fifo_vnops.c Wed Mar 16 16:25:12 2005 -@@ -531,7 +531,7 @@ - * set POLLINIGNEOF to get non-blocking behavior. - */ - if (events & (POLLIN | POLLRDNORM) && -- !(events & POLLINIGNEOF)) { -+ (events & POLLINIGNEOF)) { - events &= ~(POLLIN | POLLRDNORM); - events |= POLLINIGNEOF; - } -@@ -544,7 +544,7 @@ - /* Reverse the above conversion. */ - if ((revents & POLLINIGNEOF) && -- !(ap->a_events & POLLINIGNEOF)) { -+ (ap->a_events & POLLINIGNEOF)) { - revents |= (ap->a_events & (POLLIN | POLLRDNORM)); - revents &= ~POLLINIGNEOF; - } - - - - Shikha Shrivastava, engineer - - Dorr H. Clark, advisor COEN 284 - Operating Systems Case Study Santa Clara University, Santa Clara CA. - +*/