[MPlayer-dev-eng] [PATCH] use pthreads for caching

[Rich Felker]

On Sat, Jan 27, 2007 at 02:04:16AM +0200, Uoti Urpala wrote:
> On Fri, 2007-01-26 at 23:42 +0100, A Mennucc wrote:
> > My impression is this: after the fork, there are two signal handler
> > around; then there is a bug in the codec (or in the gmplayer GUI) that
> > triggers a signal from the Xlibs; but it gets caught in the wrong
> > signal handler; from there on , mayhem.
> 
> The forked process should be separate and there should be no way for a
> signal to be delivered "to either process" arbitrarily. The cache
> process shouldn't be running any Xlib code (if it is that's already
> broken). So I think this explanation for the problem is flawed or at
> least incomplete.

I agree. The beauty of MPlayer's cache code is that it works (or it's
supposed to work; off_t larger than system wordsize puts a nasty kink
in it..) without heavy thread-synchronization mechanisms, just simple
processes with shared memory. I suspect linking to and initializing
theads when they're not needed could active nasty locking mechanisms
in the C library (malloc, etc.) possibly causing performance loss. In
any case I insist on any thread use being optional because I cannot
use a version that requires threads, and the requirement of threads
precludes porting to certain systems.

Rich