WeaverObservers are used to receive more informative events about the thread states and job execution. The managing Weaver blocks them if no jobs are available. Threads have an eager policy in trying to execute jobs out of the queue. Threads are created on demand and do not exit until the containing weaver is deleted. Two jobs that depend on each other in both directions will simply never be executed, since the dependencies will never resolve.
It is important, though, to avoid circular dependencies. Multiple dependencies are possible, which allows the creation of complex flow graphs that are automatically executed by the Weaver. If no dependencies are declared, jobs are executed in queueing order. In this, dependencies reorder job execution. A job will only execute if all jobs it depends on are already finished. Users usually acquire a reference to a WeaverInterface object. The Weaver class provides objects that handle a number of threads called the inventory. Jobs are regular QObjects, which allows users to connect to the done() signal to be notified when the Job has been executed. The minimum and maximum number of threads provided by a Weaver is set by the user. It executes jobs in threads it internally manages.
See the information on use cases and why multithreading can help, as well as the usage section below, for more detailed information. You simply divide the workload into jobs, state the dependencies between the jobs and ThreadWeaver will work out the most efficient way of dividing the work between threads within a set of resource limits. It uses a job-based interface to queue tasks and execute them in an efficient way. ThreadWeaver is a helper for multithreaded programming.
0 kommentar(er)
