Descritor de arquivo de pesquisa

Question

Para a plataforma incorporada baseada em MIPs, estou implementando um pequeno programa para pesquisar GPIO, ou seja, estou usando a biblioteca GPIO do nível de usuário do fornecedor de chip com funcionalidade básica (Open /dev /gpio, leia, escreva pino etc.). O design é direto:

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 */
        }
    }
}

Mas estou enfrentando um problema sério - este aplicativo quando foi executado com '&' no final, ou seja, colocá -lo em segundo plano, consome 99% de CPU, isso é obviamente por causa do loop apertado, mas observei a abordagem semelhante em muitos código de rede E funcionou bem.

Estou perdendo alguma coisa, pode ser um defeito da biblioteca GPIO?

Na verdade, apenas um único "while (1);" faz o mesmo efeito. Pode ser o comportamento "natural" do kernel?

Obrigado.

Answer 1

o select A chamada deve bloquear até que o descritor do arquivo esteja legível.

O que pode estar acontecendo é que o driver do dispositivo não suporta o select Ligue e, assim, sai imediatamente, em vez de bloquear.

Outra possibilidade é que o chamado para gpio_open Na verdade, não fornece um descritor de arquivo Unix real. Se isso fosse open("/dev/gpio", O_RDWR) Ou algo assim eu teria muito mais fé.