first round, connecting overviews properly to main page
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@52042 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
@@ -8,11 +8,12 @@
|
||||
|
||||
/*!
|
||||
|
||||
@page thread_overview Multithreading overview
|
||||
@page overview_thread Multithreading overview
|
||||
|
||||
Classes: #wxThread, #wxMutex,
|
||||
#wxCriticalSection,
|
||||
#wxCondition
|
||||
|
||||
wxWidgets provides a complete set of classes encapsulating objects necessary in
|
||||
multithreaded (MT) programs: the #thread class itself and different
|
||||
synchronization objects: #mutexes and
|
||||
@@ -21,6 +22,7 @@
|
||||
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 a non-trivial undertaking especially for large
|
||||
@@ -35,6 +37,7 @@
|
||||
@ref idleevent_overview or even simply do everything at once
|
||||
but call wxWindow::Update() 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 @e is possible for many different threads to call GUI functions at once
|
||||
@@ -44,6 +47,7 @@
|
||||
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 secondary threads and the main thread, you may use
|
||||
wxEvtHandler::AddPendingEvent
|
||||
or its short version #wxPostEvent. These functions
|
||||
|
Reference in New Issue
Block a user