2017-06-30 3 views
2

J'ai essayé d'ajouter quelques fds à mio, y compris le stdin. Mon application se bloque en essayant de lire depuis stdin, après avoir reçu un événement de mio, que stdin est lisible. J'ai remarqué que mio utilise le epoll_wait et que ce syscall revient instantanément.rust mio rapporte toujours même sur stdin

strace -e trace=epoll_create,epoll_ctl,epoll_wait,read,epoll_create1 ./target/debug/ongybar 

epoll_create1(EPOLL_CLOEXEC)   = 6 
epoll_ctl(6, EPOLL_CTL_ADD, 7, {EPOLLIN|EPOLLET, {u32=4294967295, u64=18446744073709551615}}) = 0 
epoll_ctl(6, EPOLL_CTL_ADD, 3, {EPOLLIN, {u32=0, u64=0}}) = 0 
epoll_ctl(6, EPOLL_CTL_ADD, 0, {EPOLLIN, {u32=0, u64=0}}) = 0 
epoll_ctl(6, EPOLL_CTL_ADD, 4, {EPOLLIN, {u32=4, u64=4}}) = 0 
epoll_wait(6, [{EPOLLIN, {u32=4, u64=4}}], 4, -1) = 1 
read(4, "[...], 8192) = 1004 
epoll_wait(6, [{EPOLLIN, {u32=0, u64=0}}], 4, -1) = 1 
read(0, 

Le code complet que je vis cela avec est sur github.

Répondre

1

Ma forte conjecture est que non fd 0 (stdin), mais fd 3 est devenu lisible: Ici

epoll_ctl(6, EPOLL_CTL_ADD, 3, {EPOLLIN, {u32=0, u64=0}}) = 0 
epoll_ctl(6, EPOLL_CTL_ADD, 0, {EPOLLIN, {u32=0, u64=0}}) = 0 

vous pouvez voir que fd 0 et 3 sont à la fois enregistré avec epoll_data U32/U64 = 0.

Et ici

epoll_wait(6, [{EPOLLIN, {u32=0, u64=0}}], 4, -1) = 1 

vous ne pouvez en déduire que l'un des deux descripteurs de fichiers enregistrés avec u 32/u64 = 0 sont lisibles maintenant, mais vous ne pouvez pas distinguer entre fd 0 et fd 3 ici! Et depuis la lecture des blocs stdin, elle doit être fd 3.

La solution consiste à utiliser un identifiant unique pour u32/u64 pour chaque descripteur de fichier afin d'identifier correctement le descripteur de fichier correct qui avait une activité.