]>
Commit | Line | Data |
---|---|---|
1 | \section{Multithreading overview}\label{wxthreadoverview} | |
2 | ||
3 | Classes: \helpref{wxThread}{wxthread}, \helpref{wxMutex}{wxmutex}, | |
4 | \helpref{wxCriticalSection}{wxcriticalsection}, | |
5 | \helpref{wxCondition}{wxcondition} | |
6 | ||
7 | wxWidgets provides a complete set of classes encapsulating objects necessary in | |
8 | multithreaded (MT) programs: the \helpref{thread}{wxthread} class itself and different | |
9 | synchronization objects: \helpref{mutexes}{wxmutex} and | |
10 | \helpref{critical sections}{wxcriticalsection} with | |
11 | \helpref{conditions}{wxcondition}. The thread API in wxWidgets resembles to | |
12 | POSIX1.c threads API (a.k.a. pthreads), although several functions have | |
13 | different names and some features inspired by Win32 thread API are there as | |
14 | well. | |
15 | ||
16 | These classes will hopefully make writing MT programs easier and they also | |
17 | provide some extra error checking (compared to the native (be it Win32 or Posix) | |
18 | thread API), however it is still an non-trivial undertaking especially for large | |
19 | projects. Before starting an MT application (or starting to add MT features to | |
20 | an existing one) it is worth asking oneself if there is no easier and safer way | |
21 | to implement the same functionality. Of course, in some situations threads | |
22 | really make sense (classical example is a server application which launches a | |
23 | new thread for each new client), but in others it might be a very poor choice | |
24 | (example: launching a separate thread when doing a long computation to show a | |
25 | progress dialog). Other implementation choices are available: for the progress | |
26 | dialog example it is far better to do the calculations in the | |
27 | \helpref{idle handler}{wxidleevent} or call \helpref{wxYield()}{wxyield} | |
28 | periodically to update the screen. | |
29 | ||
30 | If you do decide to use threads in your application, it is strongly recommended | |
31 | that no more than one thread calls GUI functions. The thread sample shows that | |
32 | it {\it is} possible for many different threads to call GUI functions at once | |
33 | (all the threads created in the sample access GUI), but it is a very poor design | |
34 | choice for anything except an example. The design which uses one GUI thread and | |
35 | several worker threads which communicate with the main one using events is much | |
36 | more robust and will undoubtedly save you countless problems (example: under | |
37 | Win32 a thread can only access GDI objects such as pens, brushes, \&c created by | |
38 | itself and not by the other threads). | |
39 | ||
40 | For communication between threads, use | |
41 | \helpref{wxEvtHandler::AddPendingEvent}{wxevthandleraddpendingevent} | |
42 | or its short version \helpref{wxPostEvent}{wxpostevent}. These functions | |
43 | have thread safe implementation so that they can be used as they are for | |
44 | sending event from one thread to another. | |
45 | ||
46 |