Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
Hi All!
On Sun, 2007-08-05 at 19:55 +0200, Steinar H. Gunderson wrote:
>
> This is also wrong. All threads in a program share address space, which means
> that all variables are shared by default, which means that every single
> non-local variable access has the potential of a race condition. Multiprocess
> is the complete opposite -- the address spaces are separated unless you
> explicitly use shared memory. (You'll still have to lock files and such, but
> that's comparatively easy.)
I'm on a direct opposite opinion. Yes, there are some rules what you
have to keep but in other way it's easy to program. (I know I'm a
developer :)
First the stack differ in every thread so it's safe to use it. And all
local variable allocated in stack.
And yes, I know that the choosen method is depend on the function. But I
think that this function is better to implement with multithread than
multiprocess, because:
1. Reading a log message and write it to a file is highly paralellable.
2. There may be a lot of paralell reading. (the config)
3. We have to ballance the load about message, not connection because
sometimes a small number of programs (maybe one) generate a big part of
messages.
4. IIRC one of the most important reason to choose multiprocess
programing is not that multiprocessing is easier to implement than
multithreading but the memory leaks.
So if I had to choose I surely choose multithreading.
And I think that the real question is that there is place in Debian for
a multithread/process system logging daemon (against the singlethread
ones) or not. And I think that this dispute is onlt theoretical. :)
Reply to: