polling file descriptor

Question

Hello,

for the embedded MIPS-based platform I'm implementing a small program to poll GPIO, i.e. I'm using chip vendor's user level GPIO library with basic functionality (open /dev/gpio, read, write pin etc.). The design is straightforward:

int gpio_fd;
fd_set rfds;

gpio_fd = gpio_open(...);

while (1) {
    FD_ZERO(&rfds);
    FD_SET(gpio_fd, &rfds);

    if (select(gpio_fd + 1, &rfds, NULL, NULL, NULL) > 0) {
        if (FD_ISSET(gpio_fd, &rfds)) {
            /* read pins and similar */
        }
    }
}

But I'm facing a serious problem - this application when ran with '&' at the end, i.e. put it in background, consumes 99% CPU, this is obviously because of tight loop, but I observed the similar approach in many networking code and it worked fine.

Am I missing something, can it be a defect of the gpio library ?

Actually, just a single "while(1) ; " does the same effect. Can it be the "natural" behavior of the kernel?

Thanks.

Answer 1

The select call should block until the file descriptor is readable.

What may be happening is that the device driver does not support the select call, and so it exits immediately rather than blocking.

Another possibility is that the call to gpio_open does not actually give you a real Unix file descriptor. If that were open("/dev/gpio", O_RDWR) or something like that I'd have a lot more faith in it.