====== epoll ======
===== Tests =====
==== Multithreading ====
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?

===== Reenable =====
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|}}