| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
At least one instance of that problem could potentially lead
to abort (inside omfile).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
messages should be logged
this was previously not properly handeld. This is also the first occurence of
a (real) CAS loop inside rsyslog. Note that the performance is now very well
in the default configuration, and mark message directives are still correctly
being handled. So this code looks close to final, but needs to have some
bug cleanup as the testsuite shows.
|
|
|
|
| |
also: bugfix: mutexes used to similate atomic instructions were not destructed
|
| |
|
|
|
|
| |
code did not compile after merge from v4
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
runtime/Makefile.am
runtime/atomic.h
runtime/queue.c
runtime/queue.h
runtime/wti.c
runtime/wti.h
runtime/wtp.c
runtime/wtp.h
|
| |
| |
| |
| |
| |
| | |
replaced atomic operation emulation with new code. The previous code
seemed to have some issue and also limited concurrency severely. The
whole atomic operation emulation has been rewritten.
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| | |
|
| |
| |
| |
| | |
[backport of Stefen Sledz' patch for v5]
|
|\ \ |
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
tests/rt-init.c
|
| | |
| | |
| | |
| | |
| | |
| | | |
... but this is not considered a real solution. For some of the
uses, it may acutally be sufficient, but the implications need
to be analyzed in detail.
|
| | | |
|
|/ /
| |
| |
| |
| | |
Signed-off-by: Steffen Sledz <sledz@dresearch.de>
Acked-by: Thilo Fromm <t.fromm@dresearch.de>
|
| |
| |
| |
| |
| | |
... by utilizing that we need to modify a state variable only in
a sequential way during shutdown.
|
|/
|
|
|
|
| |
This may have caused a segfault under strange circumstances (but if
we just run long enough with a high enough message volume, even the
strangest circumstances will occur...)
|
|
|
|
|
| |
... as far as I think this mostly is to keep the thread debuggers
happy
|
|\ |
|
| | |
|
| |
| |
| |
| |
| | |
details are too many, for full analysis see blog post at:
http://blog.gerhards.net/2009/01/rsyslog-data-race-analysis.html
|
| | |
|
|/
|
|
|
|
| |
This enables us to use more efficient calling conventions and
also helps us keep the on-disk structure of a msg object more
consistent in future releases.
|
|
|
|
|
| |
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 ;)
|
| |
|
|
there are still some files left which could go into the
runtime, but I think we will delete most of them once we
are done with the full modularization.
|