[1.7] "broken" pipe implementation?

[Andrew Schulman]

I'm compiling screen for 1.7.  The configure script has a test for a "usable"
pipe implementation, which passes, and another one for a "working" pipe
implementation, which fails.  The test for a working pipe implementation is zero
exit code from the following program (simplified for clarity):

---
#include <sys/types.h>
#include <fcntl.h>
#include <sys/time.h>
#include <sys/stat.h>

#ifndef O_NONBLOCK
#define O_NONBLOCK O_NDELAY
#endif
#ifndef S_IFIFO
#define S_IFIFO 0010000
#endif

char *fin = "/tmp/conftest";

main()
{
  struct timeval tv;
  fd_set f;

#ifdef POSIX
  if (mkfifo(fin, 0600))
#else
  if (mknod(fin, S_IFIFO|0600, 0))
#endif
    exit(1);
  close(0);
  if (open(fin, O_RDONLY|O_NONBLOCK))
    exit(2);

  FD_SET(0, &f);
  tv.tv_sec = 1;
  tv.tv_usec = 0;
  if (select(1, &f, 0, 0, &tv))
    exit(3);
  exit(0);
}
---

When I compile and run this program, the exit code is 3, so the select() test at
the end returns non-zero.  An extra printf shows that the return value of
select() is 1.

I'm a little out of my depth here, but let me see if I understand this test
correctly:

(1) Create a FIFO (fin) and open it non-blocking, read only as fd 0.
(2) Call select() to see if the kernel thinks that fd 0 can be read from.
(3) Fail when select() returns 1, which would mean that there's data to be read.

So in other words, with nothing writing to the fifo, select() should return 0,
but instead it returns 1, indicating that there's data available to be read.  I
guess this does sound broken.  I get the same result with -DPOSIX, BTW.

Is this a known bug?  Any prospect of fixing it?  This test also failed in
Cygwin 1.5, so ever since then screen has used sockets instead of fifos.  That's
mostly worked fine, but there are some bugs that come up from time to time, and
I'd like to be able to try the fifo implementation to see if it fixes them.

BTW, if I short-circuit the test and force configure to use the fifos anyway
(instead of sockets), then when I start screen, it hangs.  strace shows the
following output repeating ad infinitum (orpie is one of the processes that I
start in my .screenrc):

   86 43297100 [unknown (0x11B4)] orpie 5808 cygwin_select: sel.always_ready 0
50267 43347367 [unknown (0x11B4)] orpie 5808 select_stuff::cleanup: calling
cleanup routines
  144 43347511 [unknown (0x11B4)] orpie 5808 select_stuff::cleanup: calling
cleanup routines
   90 43347601 [unknown (0x11B4)] orpie 5808 select_stuff::~select_stuff:
deleting select records
   87 43347688 [unknown (0x11B4)] orpie 5808 cygwin_select: 0, 0x0, 0x0, 0x0,
0x18ECCD70
   87 43347775 [unknown (0x11B4)] orpie 5808 cygwin_select: to->tv_sec 0,
to->tv_usec 50000, ms 50
   82 43347857 [unknown (0x11B4)] orpie 5808 cygwin_select: sel.always_ready 0
50140 43397997 [unknown (0x11B4)] orpie 5808 select_stuff::cleanup: calling
cleanup routines
  196 43398193 [unknown (0x11B4)] orpie 5808 select_stuff::cleanup: calling
cleanup routines
   68 43398261 [unknown (0x11B4)] orpie 5808 select_stuff::~select_stuff:
deleting select records
   64 43398325 [unknown (0x11B4)] orpie 5808 cygwin_select: 0, 0x0, 0x0, 0x0,
0x18ECCD70
   60 43398385 [unknown (0x11B4)] orpie 5808 cygwin_select: to->tv_sec 0,
to->tv_usec 50000, ms 50
   99 43398484 [unknown (0x11B4)] orpie 5808 cygwin_select: sel.always_ready 0

So it does seem that the fifo implementation is broken in some way.

Thanks,
Andrew.

--
To reply by email, change "deadspam.com" to "alumni.utexas.net"


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/