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