A thread that is done/killed should signify that the thread manager has
some processing to do -- it needs to process any messages in its out
queue, join the thread, and delete it. Otherwise the thread manager
may reach a state where it makes no progress in processing the last
remaining done/killed thread.
* origin/fastpath:
Don't build broccoli ruby bindings by default, use --enable-ruby to do so.
Revert "Fix race condition in unit test."
Fix race condition in unit test.
Change percent_lost in capture-loss from a string to a double.
Internally, Dir kept track of the files in directory
by storing all inode numbers in a set. However, when a file
is deleted and a new file is created in a directory, the old
file may get the same inode number as the old one. In this
case, bro did not notice the new file.
The patch simply changes the indexing of files - now files
are indexed by inode and creation time.
This should fix the scripts.base.utils.dir test failures.
This fix also fixes the deadlock issue without putting any
new strain into the main packet processing path.
Instead of occasionally returning true in MaybeReady sometime,
we occasionally process threads if time_mgr time is not running.
If time_mgr time is running, we have heartbeat messages that will
trigger processing in any case -- processing always checks the
exact state of the Queues.
This fix probably also means that we can remove the communication
loads from all input framework tests and run them all simultaneously.
Bernhard and I tracked it down we believe: the thread queue could
deadlock in certain cases. As a fix we tuned the heuristic for telling
if a queue might have input to occasionaly err on the safe side by
flagging "yes", so that processing will proceed.
It's a bit unfortunate to apply this fix last minute before the
release as it could potentially impact performance if the heuristic
fails to often. We believe the chosen parmaterization should be fine ...
* origin/topic/dnthayer/doc-changes-for-2.2:
Add gawk to list of optional packages
Add more script package README files
Add NEWS about new features of broctl and upgrade info
When using clang3.3 on mavericks with libc++, after the
first std::getline-call encountered eof on an ifstream,
all following std::getline calls on the same ifstream will
also get eof, even if ifstream::clear has been called and
the file has been appended in the meantime.
Seeking to the current position after a clear before trying
to read the line fixes this behavior.
This is just a temporary workaround...
BSD and debian-based Linux do not include gawk by default. Noticed
that a test was failing on these platforms due to the use of a bro-cut
option that requires gawk.
