Я пишу приложения для API, определенного как символьные устройства Linux, с большинством интересных частей API, определенных как вызовы ioctl(), где асинхронные события передаются приложению, когда драйверы вызывают POLLPRI через poll(). Я хотел бы попробовать улучшить прикладную часть этого с помощью libuv.
Я пробовал одно устройство, где драйвер ожидает вызовы read() и поэтому вызывает POLLIN. Я использовал uv_poll_t с UV_READABLE, и это было нормально. Однако по крайней мере два устройства используют POLLPRI исключительно при изменении состояния.
Эскиз кода:
int fd = open("/dev/..fancy..", O_RDWR);
if (fd < 0) { ... exit or something ... }
int res = ioctl(fd, FANCY_CONFIGURE, ...);
if (res != 0) { ... exit or something ... }
struct pollfd pfd[1] = { fd, POLLPRI, 0 };
int pr = poll(pfd, 1, -1);
if (pr != 1) { ... }
int events;
res = ioctl(fd, FANCY_GET_EVENTS, &events);
// examine events value to see what happened
Я знаю из документов и из эксперимента, что если драйвер вызывает только POLLPRI, как это требуется по спецификации, то uv_poll_t не будет работать.
Я рассматриваю какую-то комбинацию подготовки/проверки/асинхронности, но другие фреймворки (индивидуальные), созданные для работы с этим API, используют шаблон «большой вызов для опроса» и также предназначены для обработки POLLPRI. Я думаю, что если бы опросы для POLLPRI были должным образом интегрированы с чем-либо еще, что происходит в libuv (и я также много использую для сокетов libuv), это было бы более эффективным и более приятным.
Так что, если я что-то пропустил, пожалуйста, покажите мне. Если я прав, что прямая поддержка POLLPRI незначительна, я хотел бы получить несколько элегантных предложений от людей, которые разбираются в libuv.
