rsyslog.git - rsyslog development for Lumberjack - various unofficial and potentially rebased branches

	Commit message (Collapse)	Author	Age	Files	Lines
*	backported "clean" increment of memory trim counter (not protected by mutex)	Rainer Gerhards	2009-06-25	1	-0/+1
\|
*	some memory accesses are now explicitely atomic	Rainer Gerhards	2009-06-25	1	-0/+5
\| \| \| \| \|	... as far as I think this mostly is to keep the thread debuggers happy
*	Merge branch 'beta'	Rainer Gerhards	2009-01-30	1	-0/+7
\|\
\| *	added info if atomic ops are available to rsyslogd -v output	Rainer Gerhards	2009-01-30	1	-0/+7
\| \|
\| *	bugfix: inconsistent use of mutex/atomic operations could cause segfault	Rainer Gerhards	2009-01-30	1	-1/+1
\| \| \| \| \| \| \| \| \| \|	details are too many, for full analysis see blog post at: http://blog.gerhards.net/2009/01/rsyslog-data-race-analysis.html
* \|	fixed atomic operations	Rainer Gerhards	2009-01-29	1	-1/+1
\| \|
* \|	moved bParseHostname and bIsParsed to msgFlags	Rainer Gerhards	2008-10-09	1	-0/+2
\|/ \| \| \| \| \|	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.
*	bugfix: proper synchronization on message destruction	Rainer Gerhards	2008-09-19	1	-0/+1
\| \| \| \| \|	The code was potentially race, at least on systems where a memory barrier was needed. Fix not fully tested yet.
*	bugfix: potential race condition when adding messages to queue	Rainer Gerhards	2008-09-18	1	-2/+6
\| \| \| \| \| \| \|	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 ;)
*	re-enabled gcc builtin atomic operations and added a proper ./configure check	Rainer Gerhards	2008-09-18	1	-9/+9
\|
*	moved files to the runtime	Rainer Gerhards	2008-04-16	1	-0/+51
	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.