PERFORCE change 164402 for review
Zhao Shuai
zhaoshuai at FreeBSD.org
Mon Jun 15 07:16:23 UTC 2009
http://perforce.freebsd.org/chv.cgi?CH=164402
Change 164402 by zhaoshuai at 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 <gward at lmi.net>
* Compare also fifo.c
*/
+/*
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
@@ -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 <gward at lmi.net>
@@ -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.
-
+*/
More information about the p4-projects
mailing list