The change in this branch should fix the case where the last remaining done/killed thread never got processed (main thread never received pending messages from it or joined/deleted it) until Bro terminates. Which was problematic if the termination condition depended on processing messages from the last remaining thread.
The new code's logic is contrary to what it used to be, but I can't figure out what the old was trying to accomplish and think it could only have caused problems.
I looked up when the original "&& ! Killed()" code got introduced, that was in 743fc1680dc9d4c04f38ca80c7ef4e5b88e8f4cb and the commit message points to BIT-858. Can you take a look and double-check that the problem described there is still addressed with the new version to be sure we don't introduce a regression? (Not immediately sure if we have a test that covers that).
I've merged it but reopening for the double-check.
testing/btst/scripts/base/frameworks/input/missing-file.bro seems to at least be checking part of the problem mentioned in BIT-858. And I don't think that this conflicts with what was addressed there. Here's an abbreviated history of "thread termination":
threading::Manager:rocess() and threading::Manager::NextTimestamp() both check for "&& ! t->Killed()"
The assumption is that you're not allowed to read from a "dead" thread's queue and threads are only cleaned up in threading::Manager::Terminate()
threading::Manager:rocess() can now also clean up dead threads
Reading from a dead thread's queue is now supported
"&& ! t->Killed()" check is removed from threading::Manager:rocess() to allow flushing out a dead thread's queue before cleaning it up, but the check still remains in threading::Manager::NextTimestamp()
To me, looks like the NextTimestamp code just didn't evolve w/ the rest.