Die edge triggered …

./epolltest1.d --iterations=1000 --speed=0 --readers=300 --writers=50 --one --edge p w r e >/tmp/epoll.log
grep -iE "only|fail" /tmp/epoll.log
grep "I/O:.*read" /tmp/epoll.log | cut -d '"' -f 2 | sort | uniq -d
grep "I/O:.*read" /tmp/epoll.log | cut -d '"' -f 2 | wc -l

wie auch die level triggered methode …

./epolltest1.d --iterations=1000 --speed=0 --readers=300 --writers=50 --one p w r e >/tmp/epoll.log
grep -iE "only|fail" /tmp/epoll.log
grep "I/O:.*read" /tmp/epoll.log | cut -d '"' -f 2 | sort | uniq -d
grep "I/O:.*read" /tmp/epoll.log | cut -d '"' -f 2 | wc -l

funktionieren mit vielen vielen threads (auf mehreren Kernen) ohne das mehrere epoll_wait für das selbe schreib-event unterbrochen werden.

50000

Mit grep wird getestet auf

• Wurde epoll_wait beendet und vor dem lesen die Daten von einem anderen thread weggeschnappt?
• Wurde jedes Datum genau einmal gelesen?
• Wurden alle Daten gelesen?

Gehen schreib-events verloren, wenn sie zwischen dem disablen durch oneshot und reenablen geschehen und nach dem reenablen edge triggering verwendet wird? Nein!

Wie zu erwarten war, geht es bei level triggering erst recht.