thanks a lot for the review.
One thing I noticed is that setting wasKilled in the method queueEventOfDeath might affect the order in which events are processed. Actually if queueEventOfDeath is invoked while the waitingEvents queue is not empty, any subsequent calls to queuePacket might invoke processEvent for the received Packet before the packets already queued are processed (since wasKilled is true).
I guess this could happened if there are a lot of events queued in waitingEvents.
0. Let's assume that, initially, the queue waitingEvents contains N events: Event-0,...,Event-N
1. queueEventOfDeath is invoked, wasKilled is now true and the queue contains: Event-k,...,Event-N, Event-Death
2. a new Packet comes in, queuePacket is invoked. Since wasKilled is true, the new event Event-N+1 is processed right away before Event-N might have been processed.
On the other hand, my initial patch will let Event-N+1 in the queue and it will never get processed since the event of death will break the loop. Which is worse.
I attached a new patch that aims to fix the ordering issue. The idea is to keep queueing Event-N+i until the event of death has been processed and the queue is empty. I see one downside with this approach: if events keep coming in, the EventThread might not stop since the queue will never get empty.