A fix for attribrute sorting, but it's still broken if there are

[wxWidgets.git] / docs / latex / wx / tthreads.tex

diff --git a/docs/latex/wx/tthreads.tex b/docs/latex/wx/tthreads.tex
index 42234f0ad918e0f120724bdb5ceb54caae8f0929..26d769af94d69ad2dc99fd32a509e34d410acc07 100644 (file)
--- a/docs/latex/wx/tthreads.tex
+++ b/docs/latex/wx/tthreads.tex
@@ -4,5 +4,43 @@ Classes: \helpref{wxThread}{wxthread}, \helpref{wxMutex}{wxmutex},
 \helpref{wxCriticalSection}{wxcriticalsection}, 
 \helpref{wxCondition}{wxcondition}
 
-TODO
+wxWindows provides a complete set of classes encapsulating objects necessary in
+multithreaded (MT) programs: the \helpref{thread}{wxthread} class itself and different
+synchronization objects: \helpref{mutexes}{wxmutex} and 
+\helpref{critical sections}{wxcriticalsection} with 
+\helpref{conditions}{wxcondition}. The thread API in wxWindows resembles to
+POSIX1.c threads API (a.k.a. pthreads), although several functions have
+different names and some features inspired by Win32 thread API are there as
+well.
+
+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 an 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 a very poor choice
+(example: launching a separate thread when doing a long computation to show a
+progress dialog). Other implementation choices are available: for the progress
+dialog example it is far better to do the calculations in the 
+\helpref{idle handler}{wxidleevent} or call \helpref{wxYield()}{wxyield} 
+periodically to update the screen.
+
+If you do decide to use threads in your application, it is strongly recommended
+that no more than one thread calls GUI functions. The thread sample shows that
+it {\it is} possible for many different threads to call GUI functions at once
+(all the threads created in the sample access GUI), but it is a very poor design
+choice for anything except an example. The design which uses one GUI thread and
+several worker threads which communicate with the main one using 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).
+
+For communication between threads, use 
+\helpref{wxEvtHandler::AddPendingEvent}{wxevthandleraddpendingevent}
+or its short version \helpref{wxPostEvent}{wxpostevent}. These functions
+have thread safe implementation so that they can be used as they are for
+sending event from one thread to another.
+