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

[Steven M. Schultz]

Hi -

> From: Daniel Egger <degger at fhm.edu>
>
> Threads are useful if you can find blocking tasks which are
> parallelisable and thus prevent maximum cpu utilisation. Threads have
> several drawbacks, one of them are locking issues another one would
> be overhead for the thread management, another one would be harder
> debugability, another one would be the against-nature of threads versus
> processes on Unixsystems.

	To that list I would add portability issues.   Unless done carefully
	threading a program causes a  program to become less portable.

	One of the key problems is that of the default 'mutex attribute'.   
	Other systems (Solaris for example, *BSD* systems for another) use 
	'error checking' mutexes.   This difference can make a program
	almost completely unportable unless care is taken.   One method I 
	have seen used to enhance portability is to this logic when 
	initializing mutexes:

#ifdef __linux__
                pthread_mutexattr_t mu_attr;
                pthread_mutexattr_t *p_attr = &mu_attr;
                pthread_mutexattr_settype( &mu_attr, PTHREAD_MUTEX_ERRORCHECK );

#else
                pthread_mutexattr_t *p_attr = NULL;
#endif
                pthread_mutex_init( &frame_buffer_lock, p_attr );

> Please use threads only iff there's some real value in that.

	Yes indeed.   The paradigm of multiple processes communicating thru
	a shared memory segment provides many of the advantages of threads
	and is often easier to debug.

	Cheers,
	Steven Schultz
	sms at 2bsd.com