[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: aRts and threading issues
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2001-02-07 20:17:48
[Download RAW message or body]

   Hi!

On Mon, Feb 05, 2001 at 08:02:27AM +0100, Michael Matz wrote:
> The above behaviour differs from system to system, and lib to lib. Some
> systems don't have a libpthread. Some systems call it differently. The
> lowest common denominator is the following:
> 
> * Don't ever link to lib*thread yourself. Never ever.
>   Never! I can't stress this enough.
> * Use the compiler switch to link in threading stuff! (with gcc that's
>   -pthread) Compile _and_ link with this switch. This ensures the proper
>   order of libraries.
> * Build _all_ files somehow contributing to one executable either with
>   -pthread or not.

I ask myself if these are the necessary conditions to make it work.

--> If yes, then the following is our problem:

 - libqt is not compiled with -pthread
 - noatun uses libqt
 - noatun uses libmcop
  => libmcop needs to be compiled without -pthread as flag

 - mpeglib has to be compiled with -pthread
 - artsd uses mpeglib
 - artsd uses libmcop
  => libmcop needs to be compiled with -pthread flag

Consequence: every library and module that is provided by aRts has to be
compiled twice, once with and once without -pthread flag.

--> If no, then maybe the following weaker requirements are sufficient:

 * Don't ever link to lib*thread yourself. Never ever.
 * Use the compiler switch to link in threading stuff! Using it for linking
   in the executable that contains main() is enough.
 * If parts of an executable require threading, then you need to link the
   main executable with -pthread.

I think it would be much more easy to follow these conditions (in fact, it
would be mostly what Martin suggested, and what my common sense understanding
of threading problems seemed to be). The patch for doing so would be a few
lines, and wouldn't have too bad side effects. I would remove all threading
related link options from any libraries that do not require threading
themselves (like libmcop), and only link some toplevel binaries with -pthread
(artsd, and probably artsdsp, at least in one possible version).

Threading functionality for libmcop could later be put in a seperate library
(libmcop_mt), and seperated via factories, so that you get threading support
for the core libs if you link it, and don't have threading if you don't.

What do you think about that?

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]