| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
plus solving a compile problem for im3195 (which is not used
in practice, thus this did not show up before...)
|
|\ |
|
| |
| |
| |
| |
| |
| | |
- if queues could not be drained before timeout - thanks to
David Lang for pointing this out
- added link to german-language forum to doc set
|
| |
| |
| |
| | |
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
ChangeLog
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\| |
|
| |\ |
|
| | |\
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
syslogd.c
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Thanks to Frederico Nunez for providing the fix. The actual patch
was commited before this one - unfortunately I forgot to set
the author correct when commiting it and then it was pushed to
the online repository. Sorry for this ;)
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- a big one in syslogd.c, which caused messages not to be
freed when compiled for single-threading mode
- a small one in the file output handler, outchannels, when
a size-reached action was to be executed
|
|\| | | |
|
| |\| | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
if queue size reached light_delay mark, enqueuing
could potentially be blocked for a longer period of time, which
was not the behaviour desired.
|
|\| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
if that timestamp did not contain any subsecond information (the
resulting string was garbagge but should have been "0", what it now is).
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
...this improves performance and consistency and also fixes
a bug where subsecond time properties generated by imfile, imklog and
internal messages could be slightly inconsistent.
|
| | | | |
|
|\ \ \ \ |
|
| |\| | | |
|
| | |\| |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
runtime/net.c
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
because getnameinfo() is not cancel-safe, but was not guarded against
being cancelled. pthread_cancel() is routinely being called during
HUP processing.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
thanks to Michael Biebl for suggesting it
|
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
problem source is that getnameinfo() is not cancel-safe,
not that it is not thread-safe. It is now guarded against
cancellation.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
... but removed the mutex, as the problem seems to be in cancel
processing, so the mutex is no longer necessary
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- changed sequence when awakening thread
- removed no longer needed condition variable
- EXPERIMENTALLY added mutex guarding to hostname lookups
this is to be removed if it does not have any verifyable
useful effect
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I am changing the way the version number is bumped so that
viewer git merge conflicts happen. In the future, it will
be bumped immediately before release and not immediately after
(though this means I need to be more careful with interim
versions).
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
ChangeLog
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- removed newly-introduced potential deadlock in debug system
- removed unnecessary pthread_cond_signal
- a bit general cleanup
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
multi-threading
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
destructor not yet permitted because verification is
missing that a atomic opration is sufficient for the
job required
|
| |\ \ \ \ |
|
| |\ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The code was potentially race, at least on systems where
a memory barrier was needed. Fix not fully tested yet.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
There was a wrong order of mutex lock operations. It is hard to
believe that really caused problems, but in theory it could and with
threading we often see that theory becomes practice if something is only
used long enough on a fast enough machine with enough CPUs ;)
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | / / /
| | |_|/ / /
| |/| | | |
| | | | | | |
Conflicts:
doc/troubleshoot.html
|
| |\ \ \ \ \
| | | |_|/ /
| | |/| | | |
|