Xref: utzoo comp.unix.internals:863 comp.unix.sysv386:1588
Path: utzoo!attcan!uunet!lll-winken!uwm.edu!cs.utexas.edu!asuvax!hrc!uucs1!gaf
From: gaf@uucs1.UUCP (gaf)
Newsgroups: comp.unix.internals,comp.unix.sysv386
Subject: Re: Can you poll a pipe?
Message-ID: <345@uucs1.UUCP>
Date: 26 Oct 90 18:59:00 GMT
References: <1990Oct24.184556.853@esegue.segue.boston.ma.us>
Reply-To: gaf@uucs1.UUCP ()
Distribution: na
Organization: UUCS inc., Phoenix Az
Lines: 24

John R. Levine writes:

>A little experimentation shows that under ISC 2.2
>polling a pipe works nicely, but it's not clear whether that is standard
>behavior or an ISC improvement.  (There is such a thing as a streams pipe,
>but the standard pipe system call doesn't make one, it makes a nameless FIFO,
>as usual.)

That's funny - I've been told by ISC in no uncertain terms that poll()
doesn't work on a FIFO, since it isn't a streams device.  This info came
back from a bug report I gave them complaining that select() appeared not
to be working properly on FIFOs.  select() calls poll(), and as you say
poll() only works on streams devices.

It is not standard, and it is not an ISC improvement.  Getting X events
from a FIFO doesn't work for me very well.  What happens is they sit there,
all queued up, until some other X event happens (enter, leave, etc).
It seems select() (aka poll()) doesn't reject events from FIFOs, but if 
data on a FIFO is the only event happening, select() won't return.  When
some other event happens, the FIFO data gets read then.  It's a pity.
-- 
Guy Finney					It's that feeling of deja-vu
UUCS inc.   Phoenix, Az				all over again.
ncar!noao!asuvax!hrc!uucs1!gaf	sun!sunburn!gtx!uucs1!gaf