идентификатор файла опроса

Question

для встроенной платформы на базе MIPS Я реализую небольшую программу для опроса GPIO, то есть я использую библиотеку GPIO уровня пользователя чип-провайдера с базовыми функциями (open/dev/gpio, read, write pin и т. Д. .). Конструкция проста:

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

Но я столкнулся с серьезной проблемой - это приложение, когда бежал с «&» в конце, т.е. положить его в фоновом режиме, потребляет 99% CPU, это, очевидно, из-за жесткой но я наблюдал подобный подход во многих сетевых кодах, и он работал нормально.

Я что-то упускаю, это может быть дефект библиотеки gpio?

На самом деле, только один «while (1);» делает тот же эффект. Может ли это быть «естественным» поведением ядра?

Спасибо.

Answer 1

Звонок select должен блокироваться до тех пор, пока файловый дескриптор не станет читаемым.

Что может случиться, так это то, что драйвер устройства не поддерживает вызов select, и поэтому он немедленно выходит, а не блокирует.

Другая возможность заключается в том, что вызов gpio_open фактически не дает вам реального файлового дескриптора Unix. Если бы это было open("/dev/gpio", O_RDWR) или что-то в этом роде, у меня было бы больше веры в это.