Nem blokkolós I/O

Én szívtam már ilyennel jócskán. A Linuxban van egy csalás, hogy nem mindenre működik az epoll! Azt hinné az ember, hogy kellene neki, de nem működik! Teljesen beleszerettem az epollba, mert egyébként tényleg jó API, mindent is azzal akartam megcsinálni, de nem minden működött.

Ha jól emlékszem én a /dev/input/eventX-re akartam epoll-t csinálni, és nem működött. De lehet, hogy igaz se volt, nem emlékszem tisztán.

Csináltam IO-t ilyen serial device-okkal is, és már nem emlékszem pontosan az okára, de végül szálakkal csináltam meg inkább. El tudom képzelni, hogy nem megy velük az epoll. Persze kipróbálni nem kerül semmibe - csak 1-2 nap szarakodás :-)

A helyedben az olvasásra csinálnék egy szálat, ami olvassa a device input sztreamet és egy ringbuffer-be teszi az adatot, és a ringbuffert lehet a fő szálról non-blocking pollozgatni. Ha szükséges az eseményvezéreltség, akkor egy epoll képes pipe-ba lehet beírni mindent ami kijön az USB serialról, vagy egy signallal jelezni a fő szálnak, hogy van adat.

Ha jól emlékszem legutóbb úgy csináltam USB serialt, hogy egy socat processzt indítottam - megfelelően felparaméterezve, ami stdin/stdout-ra passzolja a serialt, és annak a processznek az stdin stdout-ját kezeltem a programomból (ami Java volt). Ez a legegyszerűbb, mert nem kell ioctl-ekkel vacakolni. Talán a menet közbeni lehúzás detektálása az ami így nem működött, de ebben sem vagyok már biztos. Nekem nem kellett ilyen, mert én csak játszós programokat csinálok ezekkel a techikákkal - hála a jó égnek!

(Java alatt is van egy epoll-ra épített non-blocking IO API, ami persze processz redirectre nem működik, ha jól emlékszem. Nem tudom, hogy az epoll működik-e szubprocessz IO-ra C-ben, szerencsére ilyet még nem kellett csinálnom.)

A legjobb, hogy nincs rendesen dokumentálva (legalábbis nem találtam meg), hogy mire kellene működnie és mire nem az epollnak. Csak ilyen blog posztok vannak, amikből meg lehet sejteni: https://darkcoding.net/software/linux-what-can-you-epoll/

Inkabb select(). A nonblock tulajdonsag magara az fd-re szinten lehet jo/hasznos, de soros eszkozokre, foleg ha alacsony a baud rate, akkor inkabb select() + valami fizikailag relevans timeout. Azaz valami ilyesmi:

 struct timeval         tv;
 fd_set                 set;

 tv.tv_sec=0;
 tv.tv_usec=10000;
 FD_ZERO(&set);
 FD_SET(dfd,&set);
 r=select(dfd+1,&set,NULL,NULL,&tv);

Ha r=0, akkor timeout volt (10 millisec-en belul nem jott adat), ha 0<r es a &set-ben benne marad(t) a dfd, akkor meg van adat. Ezutobbira lasd: FD_ISSET(dfd,&set) es hasonloak. 

Nem biztos, hogy működik:

sys/select.h: #define FD_SET(fd, fdsetp)      __FD_SET (fd, fdsetp)

bits/select.h: #define __FD_SET(d, s) \
 ((void) (__FDS_BITS (s)[__FD_ELT(d)] |= __FD_MASK(d)))

bits/select2.h: #define __FD_ELT(d) \
 __extension__                                                             \
 ({ long int __d = (d);                                                    \
    (__builtin_constant_p (__d)                                            \
     ? (0 <= __d && __d < __FD_SETSIZE                                     \
        ? (__d / __NFDBITS)                                                \
        : __fdelt_warn (__d))                                              \
     : __fdelt_chk (__d)); })

Szóval FD_SET() és társai újabban védettek az overflow ellen, tehát akkor nem csak az allokációra, hanem a használatra is saját makrók kellenek. Azt szokták csinálni, hogy

#undef FD_SETSIZE
#define FD_SETSIZE nagyobb_szam

az összes fd_set és társai előtt, de azért ezek egyikét sem mondanám szépnek. Miért nem szereti senki sem a poll()-t, amivel nem kell így mókolni? :-)