diff options
Diffstat (limited to 'doc/threads.doc')
| -rw-r--r-- | doc/threads.doc | 36 |
1 files changed, 18 insertions, 18 deletions
diff --git a/doc/threads.doc b/doc/threads.doc index f6226c03..951656b7 100644 --- a/doc/threads.doc +++ b/doc/threads.doc @@ -208,32 +208,32 @@ Normally, the programmer would like to include some information in the event sent to the widget. See the documentation for QCustomEvent for more information on user-defined events. -\section1 Threads and QObject subclasses +\section1 Threads and TQObject subclasses -The QObject class itself is \e reentrant. However, certain rules +The TQObject class itself is \e reentrant. However, certain rules apply when creating and using QObjects in a thread that is not the GUI thread. \list 1 -\i \e None of the QObject based classes included in the TQt library are -\e reentrant. This includes all widgets (e.g. QWidget and +\i \e None of the TQObject based classes included in the TQt library are +\e reentrant. This includes all widgets (e.g. TQWidget and subclasses), OS kernel classes (e.g. QProcess, QAccel, QTimer), and all networking classes (e.g. QSocket, QDns). -\i QObject and all of its subclasses are \e not \e thread-safe. This +\i TQObject and all of its subclasses are \e not \e thread-safe. This includes the entire event delivery system. It is important to -remember that the GUI thread may be delivering events to your QObject +remember that the GUI thread may be delivering events to your TQObject subclass while you are accessing the object from another thread. If -you are using QObject in a thread that is not the GUI thread, and you +you are using TQObject in a thread that is not the GUI thread, and you are handling events sent to this object, you \e must protect all access to your data with a mutex; otherwise you may experience crashes or other undesired behavior. -\i As a corollary to the above, deleting a QObject while pending +\i As a corollary to the above, deleting a TQObject while pending events are waiting to be delivered can cause a crash. You must not -delete the QObject directly from a thread that is not the GUI thread. -Use the QObject::deleteLater() method instead, which will cause the +delete the TQObject directly from a thread that is not the GUI thread. +Use the TQObject::deleteLater() method instead, which will cause the event loop to delete the object after all pending events have been delivered to the object. @@ -259,7 +259,7 @@ are examples of simple GUI operations: QPainter p; p.begin( mywidget ); - p.setPen( QColor( "red" ) ); + p.setPen( TQColor( "red" ) ); p.drawLine( 0,0,100,100 ); p.end(); @@ -271,8 +271,8 @@ Any operations that generate events must not be called by any thread other than the GUI thread. Examples of such operations are: \list -\i creating a QWidget, QTimer, QSocketNotifier, QSocket or other network class. -\i moving, resizing, showing or hiding a QWidget. +\i creating a TQWidget, QTimer, QSocketNotifier, QSocket or other network class. +\i moving, resizing, showing or hiding a TQWidget. \i starting or stoping a QTimer. \i enabling or disabling a QSocketNotifier. \i using a QSocket or other network class. @@ -283,7 +283,7 @@ Events generated by these operations will be lost on some platforms. \section1 Threads and Signals and Slots The Signals and Slots mechanism can be used in separate threads, as -long as the rules for QObject based classes are followed. The Signals +long as the rules for TQObject based classes are followed. The Signals and Slots mechanism is synchronous: when a signal is emitted, all slots are called immediately. The slots are executed in the thread context that emitted the signal. @@ -322,15 +322,15 @@ Some things to watch out for when programming with threads: \list -\i As mentioned above, QObject based classes are neither thread-safe -nor reentrant. This includes all widgets (e.g. QWidget and +\i As mentioned above, TQObject based classes are neither thread-safe +nor reentrant. This includes all widgets (e.g. TQWidget and subclasses), OS kernel classes (e.g. QProcess, QAccel), and all networking classes (e.g. QSocket, QDns). -\i Deleting a QObject while pending events are waiting to be delivered +\i Deleting a TQObject while pending events are waiting to be delivered will cause a crash. If you are creating QObjects in a thread that is not the GUI thread and posting events to these objects, you should not -delete the QObject directly. Use the QObject::deleteLater() method +delete the TQObject directly. Use the TQObject::deleteLater() method instead, which will cause the event loop to delete the object after all pending events have been delivered to the object. |