| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
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.
|
