-These classes will hopefully make writing MT programs easier and they also
-provide some extra error checking (compared to the native (be it Win32 or
-Posix) thread API), however it is still a non-trivial undertaking especially
-for large projects. Before starting an MT application (or starting to add MT
-features to an existing one) it is worth asking oneself if there is no easier
-and safer way to implement the same functionality. Of course, in some
-situations threads really make sense (classical example is a server application
-which launches a new thread for each new client), but in others it might be an
-overkill. On the other hand, the recent evolution of the computer hardware shows
-an important trend towards multi-core systems, which are better exploited using
-multiple threads (e.g. you may want to split a long task among as many threads
-as many CPU (cores) the system reports; see wxThread::GetCPUCount).
-
-To implement non-blocking operations without using multiple threads you have
-two other possible implementation choices:
-- using wxIdleEvent (e.g. to perform a long calculation while updating a progress dialog)
-- simply do everything at once but call wxWindow::Update() periodically to update the screen.
-
-Even if there are the ::wxMutexGuiEnter and ::wxMutexGuiLeave functions which allows
-to use GUI functions from multiple threads, if you do decide to use threads in your
-application, it is strongly recommended that <b>no more than one calls GUI functions</b>.
-The design which uses one GUI thread and several worker threads which communicate
-with the main one using @b events is much more robust and will undoubtedly save you
-countless problems (example: under Win32 a thread can only access GDI objects such
-as pens, brushes, c created by itself and not by the other threads).
+These classes hopefully make writing MT programs easier and they also provide
+some extra error checking (compared to the native - be it Win32 or Posix -
+thread API), however it is still a non-trivial undertaking especially for large
+projects. Before starting an MT application (or starting to add MT features to
+an existing one) it is worth asking oneself if there is no easier and safer way
+to implement the same functionality. Of course, in some situations threads
+really make sense (classical example is a server application which launches a
+new thread for each new client), but in others it might be an overkill. On the
+other hand, the recent evolution of the computer hardware shows an important
+trend towards multi-core systems, which are better exploited using multiple
+threads (e.g. you may want to split a long task among as many threads as many
+CPU (cores) the system reports; see wxThread::GetCPUCount).
+
+To implement non-blocking operations @e without using multiple threads you have
+two possible implementation choices:
+
+- use wxIdleEvent (e.g. to perform a long calculation while updating a progress dialog)
+- do everything at once but call wxWindow::Update() or wxApp::YieldFor(wxEVT_CATEGORY_UI)
+ periodically to update the screen.
+
+If instead you choose to use threads in your application, please read the
+following section of this overview.
+
+@see wxThread, wxThreadHelper, wxMutex, wxCriticalSection, wxCondition,
+ wxSemaphore
+
+
+
+@section overview_thread_notes Important Notes for Multi-threaded Applications
+
+When writing a multi-threaded application, it is strongly recommended that
+<b>no secondary threads call GUI functions</b>. The design which uses one GUI
+thread and several worker threads which communicate with the main one using
+@b events is much more robust and will undoubtedly save you countless problems
+(example: under Win32 a thread can only access GDI objects such as pens,
+brushes, device contexts created by itself and not by the other threads).
projects / wxWidgets.git / blobdiff