| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| |\ |
|
| | | |
|
| | |\ |
|
| | |\ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| | | |\ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
tests/Makefile.am
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
thanks to Michael Biebl for pointing the problem out
|
| | | |\ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| | | | | | | |
|
|\| | | | | | |
|
| |\ \ \ \ \ \
| | | |_|_|_|/
| | |/| | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
... thus causing them to be treated as TAG (this was a regression
introduced from the "rfc3164 strict" change in 4.5.0).
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
... thus causing them to be treated as TAG (this was a regression
introduced from the "rfc3164 strict" change in 4.5.0). Testbench has been
updated to include a smaple message with a hostname containing a dash.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
this option permites to process mark messages under all circumstances,
even if an action was recently called. This can be useful to use mark
messages as a kind of heartbeat.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
the bug fix was imported from 4.5.1, but it is important enough
to be highlighted in its own right.
|
|\| | | | | | |
|
| |\| | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In async write mode, we use modular arithmetic to index the output
buffer array. However, the counter variables accidently were signed,
thus resulting in negative indizes after integer overflow. That in turn
could lead to segfaults, but was depending on the memory layout of
the instance in question (which in turn depended on a number of
variables, like compile settings but also configuration). The counters
are now unsigned (as they always should have been) and so the dangling
mis-indexing does no longer happen. This bug potentially affected all
installations, even if only some may actually have seen a segfault.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I found out that the previous segfault fix did not correct the root
cause of the problem. Thus, I can re-instantiate the more performance-
optimal logic. In the next step, I'll merge in the real fix, so do NOT
use this commit as code you actually run!
|
| | | | | | | |
|
|\| | | | | | |
|
| |\ \ \ \ \ \ |
|
| | |/ / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I have undone a very small optimization with using pre-malloced memory,
which seems to have some issues. Now I am doing mallocs and at least in
test environment this seems to solve the issue. The code now needs more
review. If it runs flawlessly for some time, I may try to re-enable to
pre-malloc, but not necessarily: its performance benefit is very mild
(aka: I don't think it justifies introducing bigger complexities).
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
permits to specify how many TCP servers shall be possible (default is 20).
|
| | | | | | | |
|
|\| | | | | | |
|
| |\| | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Some devices seem to create them and I do not see any harm in supporting that.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
a bug showed up during further testing. As this was a side-activity,
I'll probably disable it for the time being and check what's going on
somewhat later (I'll do it tomorrow if I can find it quickly)
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
... but an alternate approach via pthread_kill. This is somewhat safer as we
do not need to think about the cancel-safeness of all libraries we use.
However, not all inputs can easily supported, so this now is a feature
that can be requested by the input module (the most important ones
request it).
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
... but this sets stage for potential future optimizations, especially
the capability to use multiple reception threads.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
the new handling will hopefully spare a few cycles, as function calls
(and most importantly parameter generation!) or now only done when
debug messages are actually active.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
code review brought up some few places where we may have run into a race.
They have most probably been introduced during the recent set of changes. But
I do not look at older versions because of the changed architecture, one can
not simply backport this patch.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This did NOT leak based on message volume. Also, did some cleanup during
the commit.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
... greater performance and was able to remove a potential troublespot
in a cancel cleanup handler.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
...if not running in direct mode. Previous versions could run without
any active workers. This simplifies the code at a very small expense.
See v5 compatibility note document for more in-depth discussion.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
... as well as some cleanup
|