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

List:       kde-multimedia
Subject:    aRts & threading
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2001-02-26 20:58:03
[Download RAW message or body]

   Hi!

Threading in aRts is in a working state now. The following changed:

1. Support for development of threaded apps/classes (in libmcop/libmcop_mt):

 * there are additional classes Arts::Thread, Arts::Mutex and Arts::Thread-
   Condition (documentation at http://www.arts-project.org/doc/headers)
 * they are defined libmcop, with empty implementation (that is they do
   nothing if you just link libmcop)
 * there is a new library, libmcop_mt, which provides "real" implementations
   for it (using libpthread, but one can add other possibilities there)
 * linking against libmcop_mt enables threading support

2. Thread safety for aRts apps/classes:

 * there is a global lock around all aRts stuff, which you can get/release
   with Arts::Dispatcher::lock()/unlock()
 * you can send requests, create objects, send notifications and do whatever
   you want with aRts from arbitary threads, given you hold the lock
 * there is a new Arts::Dispacher::wakeup() function, which wakes up the
   main event loop (so if you queue for instance DataPackets/Notifications,
   you can wake up the main event loop to dispatch them)

3. Example code:

 * the headers of the thread classes contain some kdoc-able examples
 * kdelibs/examples/testthreads, testnothreads (same program, once built
   with -lmcop and once with -lmcop_mt)
 * http://space.twc.de/~stefan/kde/download/artsmikmod.tar.gz - a mikmod
   PlayObject based using a seperate thread - I used this one for testing

The basic concept is: make threading optional for aRts/MCOP apps, but build
all core libraries to support it nicely. I.e. the Dispatcher has a mutex for
protecting things. If you don't link libmcop_mt, it will use a dummy-
implementation, so it will not be threadsafe. So objects that require
threading will not work in a context of a non-threaded dispatcher. But on
the other hand, if you do link libmcop_mt, you will be able to load threaded
plugins, and they will work.

It is also possible to explicitely write code for both situations:
   if(SystemThreads::the()->supported()) /*threaded magic*/ else /*no magic*/;

I hope that we can solve the problem of non-threaded-KDE-plugins which need
to use libmcop (i.e. a kpart for playing media files) with that, and I hope
it will be portable, too. Right?

Now would be a good time to suggest why this should be done differently, what
is missing, what is broken and so on. ;-)

   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]