[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