[MPlayer-dev-eng] MplayerXP vs Mplayer. Hall of truth.

[Gábor Lénárt]

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