• Skip to content
  • Skip to link menu
KDE 4.3 API Reference
  • KDE API Reference
  • kdelibs
  • Sitemap
  • Contact Us
 

ThreadWeaver

Main Components of ThreadWeaver

Overview | Use Cases | Why Multithreading? | Main Components

ThreadWeaver is a Job queue. It executes jobs in threads it internally manages. The minimum and maximum number of threads provided by a Weaver is set by the user. Jobs are regular QObjects, which allows users to connect to the done() signal to be notified when the Job has been executed. The Weaver class provides objects that handle a number of threads called the inventory. Users usually acquire a reference to a WeaverInterface object.

Jobs may depend on other jobs. A job will only execute if all jobs it depends on are already finished. In this, dependencies reorder job execution. If no dependencies are declared, jobs are executed in queueing order. Multiple dependencies are possible, which allows the creation of complex flow graphs that are automatically executed by the Weaver. It is important, though, to avoid circular dependencies. Two jobs that depend on each other in both directions will simply never be executed, since the dependencies will never resolve.

Threads are created on demand and do not exit until the containing weaver is deleted. Threads have an eager policy in trying to execute jobs out of the queue. The managing Weaver blocks them if no jobs are availabe.

WeaverObservers are used to receive more informative events about the thread states and job execution. They can be used to provide progress or debugging information or to implement GUIs to show the thread activity. Observers can be attached to Weavers and will disconnect automatically when they are deleted.

Execution

In general, jobs are executed in the order they are queued, if they have no unresolved dependencies. This behaviour can be used to balance I/O, network and CPU load. The SMIV example shows how this can be done.

Signals from Jobs

To notify the application's GUI of progress or other events, it may be desirable to emit signals from the Job objects that can be connected to the main thread. Since the job will be executed in another thread, such signals are delivered asynchroneously.

There is a pitfall to this that Job class developers need to be aware of. The Job objects are usually created in the main thread, and Job::thread() will return the GUI thread's id because of that. When signals are emitted, this will fool Qt to consider those to be signals between QObjects owned by the same thread, and deliver them syncroneously. The solution is to not emit the signals directly, but create a helper QObject derived class that has the same signals, create an object of this class when the job is executed, and emit the signals from there. Since this object will be created in the context of the executing thread, the signals will be delivered asyncronously again.

The Job class in the ThreadWeaver library itself contains such a helper class that can be used as a reference for this approach.

ThreadWeaver

Skip menu "ThreadWeaver"
  • Main Page
  • Namespace List
  • Class Hierarchy
  • Alphabetical List
  • Class List
  • File List
  • Namespace Members
  • Class Members
  • Related Pages

kdelibs

Skip menu "kdelibs"
  • DNSSD
  • Interfaces
  •   KHexEdit
  •   KMediaPlayer
  •   KSpeech
  •   KTextEditor
  • Kate
  • kconf_update
  • KDE3Support
  •   KUnitTest
  • KDECore
  • KDED
  • KDEsu
  • KDEUI
  • KDocTools
  • KFile
  • KHTML
  • KImgIO
  • KInit
  • kio
  • KIOSlave
  • KJS
  •   KJS-API
  •   WTF
  • kjsembed
  • KNewStuff
  • KParts
  • KPty
  • Kross
  • KUtils
  • Nepomuk
  • Plasma
  • Solid
  • Sonnet
  • ThreadWeaver
Generated for kdelibs by doxygen 1.6.1
This website is maintained by Adriaan de Groot and Allen Winter.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V. | Legal