Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

name wxThreadEvent and YieldFor in wxProgressDialog and in thread overview; update the sample code to use new event macros; minor other changes

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@59002 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Francesco Montorsi
2009-02-18 19:32:00 +00:00
parent c4021a7920
commit 3a5677401f
5 changed files with 63 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/doxygen/overviews/thread.h
View File

@@ -13,10 +13,13 @@
/**
@page overview_thread Multithreading
@page overview_thread Multithreading Overview
Classes: wxThread, wxThreadHelper, wxMutex, wxCriticalSection, wxCondition, wxSemaphore
@section overview_thread_intro When to use multiple threads
wxWidgets provides a complete set of classes encapsulating objects necessary in
multithreaded (MT) programs: the wxThread class itself and different
synchronization objects: mutexes (see wxMutex) and critical sections (see
@@ -45,13 +48,17 @@ 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 also
the following sections of this overview.
If instead you choose to use threads in your application, it is strongly recommended
@section overview_thread_notes Important notes for multithreaded 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, c created by itself and not by the other threads).
as pens, brushes, device contexts created by itself and not by the other threads).
For communication between secondary threads and the main thread, you may use
wxEvtHandler::QueueEvent or its short version ::wxQueueEvent. These functions
@@ -62,6 +69,19 @@ synchronization classes to implement the solution which suits your needs
yourself. In particular, please note that it is not enough to derive
your class from wxThread and wxEvtHandler to send messages to it: in fact, this
does not work at all.
You're instead encouraged to use wxThreadHelper as it greatly simplifies the
communication and the sharing of resources.
You should also look at the wxThread docs for important notes about secondary
threads and their deletion.
Last, remember that if wxEventLoopBase::YieldFor() is used directly or indirectly
(e.g. through wxProgressDialog) in your code, then you may have both re-entrancy
problems and also problems caused by the processing of events out of order.
To resolve the last problem wxThreadEvent can be used: thanks to its implementation
of the wxThreadEvent::GetEventCategory function wxThreadEvent classes in fact
do not get processed by wxEventLoopBase::YieldFor() unless you specify the
@c wxEVT_CATEGORY_THREAD flag.
See also the @sample{thread} for a sample showing some simple interactions
between the main and secondary threads.