On Mon, Mar 18, 2002 at 11:47:42AM +0100, Dariusz Pietrzak wrote:
mailbox, mostly worthless flames about "mplayerxp". Nick, go ahead really care what you do as long as you stop flooding my mailbox with crap. I expect most of the rest of the people on the list feel the Actually I find this discussion quite valuable, there are some quite interesting questions asked AND answered ( some of those answers i'm still waiting for.. ;)
and about threads - I was always under impression that those are windoze stuff, due to very hevyweight processess there. And under normall circumstances processes with shm are much better. And on multi-cpu systems threads could be disastrous - they create cache coherency problems ( sine in thread ALL of data is shared, all of it must be synced between CPUs, so it wastes gobs of memory bandwith ), with procs you explicitly mark data that should be shared and thus synced.
AFAIK it's not true. After fork()'ing processes has got SHARED data area, an Linux kernel will copy pages 'on demand'. Kernel won't duplicate data area at forking but on runtime, as needed. However threads and fork() is almost the same, both of them uses clone() syscall but with different flags (CLONE_VM afaik). And I think threads are BETTER than fork()'ed processes (it's true that it's much harder to implement a GOOD program with threads, due to programming faults at locking data areas between threads and so on, but IN theory, threads are better). And cache problem it the problem of scheduler in the kernel, I think mingo's O(1) patch can do quite nice work in this area too (however it's an SMP problem not UP). And threads are more lightweight contexts than processes. OF COURSE it's the best to implement something WITHOUT threads _AND_ multiple fork()'ed processes on UP (not on SMP of course ;-). - Gábor