'aRts and threading issues'

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

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

   Hi!

On Sat, Feb 03, 2001 at 03:40:55PM +0100, Martin Vogt wrote:
> > On Wed, Jan 31, 2001 at 01:24:39PM +0100, Martin Vogt wrote:
> > > On Wed, Jan 31, 2001 at 01:37:05AM -0800, Neil Stevens wrote:
> > > > Noatun loads slowly on systems with slow dynamic loaders.  So, noatun can 
> > > > be inconvenient for playing a single file.  This can make KDE look bad.
> > > > 
> > > > Konqueror is the ultimate browser, with a flexible embedding system.  Yet, 
> > > > it cannot embed a simple sound file on a web page, because no kpart for 
> > > > that exists.  This can make KDE look bad.
> > > > I see a problem here with pthreads.
> > I begin to *hate* pthreads :(
> 
> The only application which should be linked against
> pthread is artsd itsself.
> There is no need to link :
> 
> * libmcop_nothreads
> * libartsflow_idl_nothreads
> * libkmedia2_idl_nothreads
> * libsoundserver_idl_nothreads
> 
> These libs against pthread too.
> If I look at the artsd Makefile am. I dont see where it is linked
> against pthread.

It is linked implicitely, as libmcop is linked against libpthread. The idea
behind this was to force all applications which use libmcop to pull in
libpthread. Why? Because all applications that use libmcop can load plugins,
and plugins (like mpeglib) might require threads.

But given the situations, IF it would solve all problems if we get rid of
that, I can imagine giving this idea up, and link only artsd (and maybe
some other apps which explicitely want to load threaded plugins) against
libpthread. Given we solve the problem below. (Maybe it's not even a problem?).

> One important point is that pthread is the _last_ lib in the linking
> order.
> 
> Example 
> 
> -lmcop -lpthread -lartsflow
> 
> may cause problems,but: 
> 
> -lmcop -lartsflow -lpthread
> 
> is ok.
> (The dynamic linker loads libraries in the reversed linking order)
> In this case: pthread first.
> There is not need to link other libs against pthread.   

Hm. What about

-lmcop -lmcop-mt -lpthread -lartsflow -lasound -lpthread -lstdc++ -lm -lc -lgcc

This is not a theoretical question. It's a very practical problem we are
running into. For KDE2.2, I want to enable aRts to at least know about
threads (i.e. provide locks and communication with the main loop), to make
things like synchronization of streams with multithreaded plugins possible
(for mpeglib-seeking/synchronization).

I could put these synchronization primitives into an extra library (libmcop-mt)
and provide them only if you have linked against libmcop-mt. That way, if
you don't link against libmcop-mt, threaded plugins *will* break, but on the
other hand, you need no threads (i.e. can run as kpart). Of course, artsd
would link against libmcop-mt, then.

Now to the above link line: this would be the result of what libtool
thinks would be appropriate when you you use libmcop, libmcop-mt and
libartsflow. There are two problems, I can see:

 * libpthread would get linked twice, once as "quite last" and once quite
   early - the reason for this is, that since libmcop-mt will use threading
   primitives, it would depend on libpthread, and libtool likes to pull in
   dependant libs for libraries you use automatically

 * libpthread doesn't get linked as *last* library - this is because libtool
   always seems to add libstdc++ and the other stuff as last library - this
   might be the reason why artsd/mpeglib breaks completely on FreeBSD, IRIX
   and some other platforms (#11514, #16648, #18447)

If the linking order is indeed critical for libpthread stuff (I don't know,
because it always works here), maybe we could solve the problem with either
an extra libtool flag, or automatic reordering, to ensure that libpthread

 * gets only linked once
 * gets linked as last library

Here for comparision the current autogenerated link-line for artsd:

g++ -O2 -fno-exceptions -fno-check-new -Wall -pedantic -W -Wpointer-arith \
-Wmissing-prototypes -Wwrite-strings -Wno-long-long -Wnon-virtual-dtor -fno-builtin \
-frtti -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -DQT_NO_ASCII_CAST -o .libs/artsd \
soundserver_impl.o simplesoundserver_impl.o artsd.o cpuusage.o \
./.libs/libsoundserver_idl.so \
/home/stefan/build/kdelibs/arts/soundserver/.libs/libkmedia2_idl.so \
-L/usr/lib/gcc-lib/i386-linux/2.95.3 ../../arts/flow/.libs/libartsflow.so \
/home/stefan/build/kdelibs/arts/flow/.libs/libartsflow_idl.so \
/home/stefan/build/kdelibs/arts/mcop/.libs/libmcop.so -lpthread -ldl -L/usr/X11R6/lib \
-L/usr/local/qt/lib -L/usr/local/kde/lib /usr/local/kde/lib/libaudiofile.so \
/usr/lib/libasound.so -lstdc++ -lm -lc -lgcc -Wl,--rpath -Wl,/usr/local/kde/lib

As you see, libpthread is not really the last lib.

Any ideas? Michael (you usually know about these things)?

   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] 