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

joinable and detached POSIX threads (not fully tested yet)

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@4769 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Vadim Zeitlin
1999-11-29 23:05:23 +00:00
parent 7d3a036dc4
commit 9fc3ad34c5
7 changed files with 836 additions and 328 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
docs/latex/wx/thread.tex
View File

@@ -8,6 +8,25 @@ much easier to share common data between several threads, it also makes much
easier to shoot oneself in the foot, so careful use of synchronization objects
such as \helpref{mutexes}{wxmutex} and/or \helpref{critical sections}{wxcriticalsection} is recommended.
There are two types of threads in wxWindows: {\it detached} and {\it joinable}
ones, just as in POSIX thread API (but unlike Win32 threads where all threads
are joinable). The difference between the two is that only joinbale threads
can return a return code - it is returned by Wait() function. The detached
threads (default) can not be waited for.
You shouldn't hurry to create all the threads joinable, however, because this
has a disadvantage as well: you {\bf must} Wait() for a joinable thread of the
system resources used by it will never be freed and you also must delete the
corresponding wxThread object yourself, while detached threads are of the
"fire-and-forget" kind: you only have to start a detached thread and it will
terminate and destroy itself.
This means, of course, that all detached threads {\bf must} be created on the
heap because the thread will call {\tt delete this;} upon termination. The
joinable threads may be created on stack (don't create global thread objects
because they allocate memory in their constructor which is a badthing to do),
although usually they will be created on the heap as well.
\wxheading{Derived from}
None.
@@ -84,6 +103,10 @@ created. Moreover, it must be called if \helpref{Create}{wxthreadcreate} or
occupied by the thread object (it will be done in the destructor for joinable
threads).
Delete() may be called for thread in any state: running, paused or even not yet created. Moreover,
it must be called if \helpref{Create}{wxthreadcreate} or \helpref{Run}{wxthreadrun} fail to free
the memory occupied by the thread object.
For detached threads Delete() will also delete the C++ thread object, but it
will not do this for joinable ones.

7
docs/latex/wx/tthreads.tex
View File

@@ -8,7 +8,10 @@ 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}.
\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)
@@ -21,7 +24,7 @@ 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}
\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