path: root/syslogd.c
diff options
authorRainer Gerhards <>2008-03-28 17:21:43 +0000
committerRainer Gerhards <>2008-03-28 17:21:43 +0000
commit86c5a1cf89eadd393d3550c7a3114892cb39ae34 (patch)
tree68af353d5fd3954d8b721fdfa15edb18f9a3fba2 /syslogd.c
parent53a178cd0f7b23d379572fad427db035ad2d8030 (diff)
some cleanup
Diffstat (limited to 'syslogd.c')
1 files changed, 1 insertions, 36 deletions
diff --git a/syslogd.c b/syslogd.c
index 1000776..1c31fb6 100644
--- a/syslogd.c
+++ b/syslogd.c
@@ -1608,43 +1608,8 @@ logmsg(msg_t *pMsg, int flags)
/* ---------------------- END PARSING ---------------- */
- /* rgerhards, 2005-10-13: if we consider going multi-threaded, this
- * is probably the best point to split between a producer and a consumer
- * thread. In general, with the first multi-threaded approach, we should
- * NOT try to do more than have a single producer and consumer, at least
- * if both are from the current code base. The issue is that this code
- * was definitely not written with reentrancy in mind and uses a lot of
- * global variables. So it is very dangerous to simply go ahead and multi
- * thread it. However, I think there is a clear distinction between
- * producer (where data is received) and consumer (where the actions are).
- * It should be fairly safe to create a single thread for each and run them
- * concurrently, thightly coupled via an in-memory queue. Even with this
- * limited multithraeding, benefits are immediate: the lengthy actions
- * (database writes!) are de-coupled from the receivers, what should result
- * in less likely message loss (loss due to receiver overrun). It also allows
- * us to utilize 2-cpu systems, which will soon be common given the current
- * advances in multicore CPU hardware. So this is well worth trying.
- * Another plus of this two-thread-approach would be that it can easily be configured,
- * so if there are compatibility issues with the threading libs, we could simply
- * disable it (as a makefile feature).
- * There is one important thing to keep in mind when doing this basic
- * multithreading. The syslog/tcp message forwarder manipulates a structutre
- * that is used by the main thread, which actually sends the data. This
- * structure must be guarded by a mutex, else we will have race conditions and
- * some very bad things could happen.
- *
- * Additional consumer threads might be added relatively easy for new receivers,
- * e.g. if we decide to move RFC 3195 via liblogging natively into rsyslogd.
- *
- * To aid this functionality, I am moving the rest of the code (the actual
- * consumer) to its own method, now called "processMsg()".
- *
- * rgerhards, 2005-10-25: as of now, the dual-threading code is now in place.
- * It is an optional feature and even when enabled, rsyslogd will run single-threaded
- * if it gets any errors during thread creation.
- */
+ /* now submit the message to the main queue - then we are done */
pMsg->msgFlags = flags;
queueEnqObj(pMsgQueue, pMsg->flowCtlType, (void*) pMsg);