Die //edge triggered// ...
<code bash>
./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
</code>
wie auch die //level triggered// methode ...
<code bash>
./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
</code>
funktionieren mit vielen vielen threads (auf mehreren Kernen) ohne das mehrere ''epoll_wait'' für das selbe schreib-event unterbrochen werden.
<code>
50000
</code>
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!
{{:uni:ba:epoll-et.png|}}
Wie zu erwarten war, geht es bei //level triggering// erst recht.
{{:uni:ba:epoll-lt.png|}}