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. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
