poll() and events==0
phil-new...@ipal.net
What I have discovered is that if I have no requested events for
a given fd, e.g. the events member of the struct for that fd is
zero, poll() flags a POLLHUP event and returns. While reading
the man page for poll(), there is no indication that events==0
is an invalid condition. IWSTM that if I'm not interested in
any events for a particular fd, none should be reported. What
is the official behaviour for poll() in this case?
What I'm trying to do is avoid having to construct the array of
struct pollfd each time poll() is called on the theory that it
is more CPU work to construct it, that for the kernel to skip
uninteresting elements, when there are more that are interesting
(idle network connections, for example).
--
-----------------------------------------------------------------
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| phil-...@ipal.net | Texas, USA | http://phil.ipal.org/ |
-----------------------------------------------------------------
Derek M. Flynn
> I have a list of file descriptors in an array of struct pollfd.
> What I have discovered is that if I have no requested events for
> a given fd, e.g. the events member of the struct for that fd is
> zero, poll() flags a POLLHUP event and returns. While reading
> the man page for poll(), there is no indication that events==0
> is an invalid condition. IWSTM that if I'm not interested in
> any events for a particular fd, none should be reported. What
> is the official behaviour for poll() in this case?
My manual page says:
The event flags
POLLHUP, POLLERR, and POLLNVAL are always set in revents
if the conditions they indicate are true; this occurs even
though these flags were not present in events.
phil-new...@ipal.net
But in the case I ran, POLLHUP was not a truthful condition. At least
I don't think it should be when it is reading from a pipe or a file.
And when I did need to actually do read, and did read, and go EAGAIN
(in the case of the pipe), there was no POLLHUP there.
In the case I'm doing, the buffer space to read into has filled up and
I'm doing no further reading until space becomes available. That will
happen when write() on another fd completes and empties out some space.
But in the mean time, the code is hard-spinning around poll() that
keeps on returning.
So I have to rebuild the whole struct pollfd array each time?
Casper H.S. Dik - Network Security Engineer
phil-new...@ipal.net writes:
>So I have to rebuild the whole struct pollfd array each time?
No, not really. If you're temporarily not interested in the fd, you
can make it negative. (You're celaring events anyway):
pfd[n].events = 0;
if (pfd[n].fd >=0)
/* Map fd 0 .. maxint to -1 .. minint */
pfd[n].fd = -pfd[n].fd - 1;
and later:
pfd[n].events = event;
if (pfd[n].fd < 0)
/* Map fd back */
pfd[n].fd = -(pfd[n].fd + 1);
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
phil-new...@ipal.net
|>So I have to rebuild the whole struct pollfd array each time?
|
| No, not really. If you're temporarily not interested in the fd, you
| can make it negative. (You're celaring events anyway):
|
| pfd[n].events = 0;
| if (pfd[n].fd >=0)
| /* Map fd 0 .. maxint to -1 .. minint */
| pfd[n].fd = -pfd[n].fd - 1;
|
| and later:
|
| pfd[n].events = event;
| if (pfd[n].fd < 0)
| /* Map fd back */
| pfd[n].fd = -(pfd[n].fd + 1);
So the definition of poll() says a negative fd causes the slot to
be ignored?
I guess these Linux man pages just cannot be trusted. Would be
nice to have some "official" man pages around that reflect no
more and no less the POSIX standard for things that are POSIX.
Andrew Gierth
phil> So the definition of poll() says a negative fd causes the slot
phil> to be ignored?
Certainly the SUS documentation for it says that:
If the value of fd is less than 0, events is ignored and revents
is set to 0 in that entry on return from poll().
It doesn't seem to be explicitly stated how events==0 for a
non-negative fd is supposed to be handled. The behaviour you're observing
is certainly a violation of the Principle of Least Astonishment....
--
Andrew.
comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
or <URL: http://www.whitefang.com/unix/>
Casper H.S. Dik - Network Security Engineer
phil-new...@ipal.net writes:
>So the definition of poll() says a negative fd causes the slot to
>be ignored?
Yes.
Solaris manual page:
If the value fd is less than zero, events is ignored and
revents is set to 0 in that entry on return from poll().
>I guess these Linux man pages just cannot be trusted. Would be
>nice to have some "official" man pages around that reflect no
>more and no less the POSIX standard for things that are POSIX.
The opengroup has teh standard specification manual pages on-line./