KPIM::ThreadWeaver::Job Class Reference
A Job is a simple abstraction of an action that is to be executed in a thread context. More...
#include <weaver.h>
Inherits QObject.
Signals
Public Member Functions
- Job (QObject *parent=0, const char *name=0)
- virtual ~Job ()
- virtual void execute (Thread *)
- virtual bool isFinished () const
- void wakeAPR ()
- virtual void processEvent (Event *)
Protected Member Functions
- void lock ()
- void unlock ()
- virtual void run ()=0
- Thread * thread ()
- virtual void setFinished (bool status)
- void triggerSPR ()
- void triggerAPR ()
Protected Attributes
- bool m_finished
- QMutex * m_mutex
- Thread * m_thread
- QWaitCondition * m_wc
Detailed Description
A Job is a simple abstraction of an action that is to be executed in a thread context.It is essential for the ThreadWeaver library that as a kind of convention, the different creators of Job objects do not touch the protected data members of the Job until somehow notified by the Job. See the SPR signal for an example.
Jobs may emit process requests as signals. Consider process requests as a kind of synchronized call to the main thread. Process Requests are a generic means for Job derivate programmers to have the jobs interact with the creators (in the main thread) during processing time. To avoid race conditions and extensive locking and unlocking, the thread executing the job is suspended during the period needed to process the request.
There are two kinds of process requests (we introduce abbreviations, also in the signal names and the code, only to save typing). Both are emitted by signals in the main thread:
- Synchronous Process Requests (SPR): Synchronous requests expect that the complete request is performed in the slots connected to the signals. For example, to update a widget according to the progress of the job, a SPR may be used. In such cases, the Job's execution will be resumed immediately after the signal has been processed.
- Asynchronous Process Requests (APR): For APRs, the job emitting the signal does not assume anything about the amount of time needed to perform the operation. Therefore, the thread is not waked after the signal returns. The creator has to wake to thread whenever it is ready by calling the wakeAPR method.
Note: When using an APR, you better make sure to receive the signal with some object, otherwise the calling thread will block forever!
Constructor & Destructor Documentation
|
Construct a Job object.
|
|
Destructor.
|
Member Function Documentation
|
Perform the job. The thread in which this job is executed is given as a parameter. Do not overload this method to create your own Job implementation, overload run(). |
|
Returns true if the jobs's execute method finished.
|
|
Wake the thread after an APR has been processed.
|
|
Process events related to this job (created by the processing thread or the weaver or whoever).
|
|
This signal is emitted when a thread starts to process a job.
|
|
This signal is emitted when a job has been finished.
|
|
This signal is emitted when the job needs some operation done by the main thread (usually the creator of the job). It is important to understand that the emitting thread is suspended until the signal returns. When the operation requested has been performed and this signal is finished, the thread is automatically waked. What operation needs to be performed has to be negotiated between the two objects. Note: This signal is an attempt to provide job programmers with a generic way to interact while the job is executed. I am interested in feedback about it's use. |
|
Perform an Asynchronous Process Request. See SPR and the generic Job documentation for a comparison. |
|
Lock this Job's mutex.
|
|
Unlock this Job's mutex.
|
|
The method that actually performs the job. It is called from execute(). This method is the one to overload it with the job's task. |
|
Return the thread that executes this job. Returns zero of the job is not currently executed. |
|
Call with status = true to mark this job as done.
|
|
Trigger a SPR. This emits a signal in the main thread indicating the necessity of a synchronized operation. |
|
Trigger an APR. This emit a signal in the main thread indicating the necessity of an unsynchronized operation. The calling thread needs to ensure to wake the thread when the operation is done. |
The documentation for this class was generated from the following files:
- weaver.h
- weaver.cpp