[Bro-Dev] [JIRA] (BIT-1093) topic/jsiwek/thread-termination
Jon Siwek (JIRA)
jira at bro-tracker.atlassian.net
Wed Oct 30 08:58:03 PDT 2013
[ https://bro-tracker.atlassian.net/browse/BIT-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14503#comment-14503 ]
Jon Siwek commented on BIT-1093:
--------------------------------
{{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":
743fc1680dc9d4c04f38ca80c7ef4e5b88e8f4cb
- threading::Manager::Process() 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()
38e1dc9ca47d97508276a2f7192c5353bb8e6837
- threading::Manager::Process() can now also clean up dead threads
b947394990720032ac7f374f7c9d1902ed4485b9
- Reading from a dead thread's queue is now supported
- "{{&& ! t->Killed()}}" check is removed from threading::Manager::Process() 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.
> topic/jsiwek/thread-termination
> -------------------------------
>
> Key: BIT-1093
> URL: https://bro-tracker.atlassian.net/browse/BIT-1093
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: git/master
> Reporter: Jon Siwek
> Assignee: Robin Sommer
> Fix For: 2.2
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.2-OD-01#6204)
More information about the bro-dev
mailing list