| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
[backport of Stefen Sledz' patch for v5]
|
|
|
|
|
|
| |
... 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.
|
| |
|
|
|
|
|
| |
... 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.
|