removed unneeded (after patch 1027243) disable.bmp

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

diff --git a/docs/latex/wx/thread.tex b/docs/latex/wx/thread.tex
index 558d3cc70904e8b1b34a98c9773c13529364c6fb..8d16307390448da98735058b1c183249562fcd0c 100644 (file)
--- a/docs/latex/wx/thread.tex
+++ b/docs/latex/wx/thread.tex
@@ -4,11 +4,11 @@ A thread is basically a path of execution through a program. Threads are
 sometimes called {\it light-weight processes}, but the fundamental difference
 between threads and processes is that memory spaces of different processes are
 separated while all threads share the same address space. While it makes it
-much easier to share common data between several threads, it also makes much
+much easier to share common data between several threads, it also makes it 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}
+There are two types of threads in wxWidgets: {\it detached} and {\it joinable}
 ones, just as in the POSIX thread API (but unlike Win32 threads where all threads
 are joinable). The difference between the two is that only joinable threads
 can return a return code -- this is returned by the Wait() function. Detached
@@ -26,7 +26,9 @@ heap because the thread will call {\tt delete this;} upon termination. Joinable
 threads may be created on the stack although more usually they will be created
 on the heap as well. Don't create global thread objects because they allocate
 memory in their constructor, which will cause problems for the memory checking
-system.
+system. Finally, another consequence of the handling of the above is that you
+should never delete a detached thread yourself, as this will be done by the
+thread itself when it terminates.
 
 \wxheading{Derived from}
 
@@ -102,7 +104,7 @@ One of:
 
 Calling \helpref{Delete}{wxthreaddelete} is a graceful way to terminate the
 thread. It asks the thread to terminate and, if the thread code is well
-written, the thread will terminate after the next call to
+written, the thread will terminate after the next call to 
 \helpref{TestDestroy}{wxthreadtestdestroy} which should happen quite soon.
 
 However, if the thread doesn't call \helpref{TestDestroy}{wxthreadtestdestroy}
@@ -134,7 +136,7 @@ be implemented by any derived class. The thread execution will start here.
 The returned value is the thread exit code which is only useful for
 joinable threads and is the value returned by \helpref{Wait}{wxthreadwait}.
 
-This function is called by wxWindows itself and should never be called
+This function is called by wxWidgets itself and should never be called
 directly.
 
 
@@ -341,17 +343,21 @@ Sets the thread concurrency level for this process. This is, roughly, the
 number of threads that the system tries to schedule to run in parallel.
 The value of $0$ for {\it level} may be used to set the default one.
 
-Returns true on success or false otherwise (for example, if this function is
+Returns \true on success or false otherwise (for example, if this function is
 not implemented for this platform -- currently everything except Solaris).
 
 
 \membersection{wxThread::TestDestroy}\label{wxthreadtestdestroy}
 
-\func{bool}{TestDestroy}{\void}
+\func{virtual bool}{TestDestroy}{\void}
 
 This function should be called periodically by the thread to ensure that calls
 to \helpref{Pause}{wxthreadpause} and \helpref{Delete}{wxthreaddelete} will
-work. If it returns true, the thread should exit as soon as possible.
+work. If it returns \true, the thread should exit as soon as possible.
+
+Notice that under some platforms (POSIX), implementation of 
+\helpref{Pause}{wxthreadpause} also relies on this function being called, so
+not calling it would prevent both stopping and suspending thread from working.
 
 
 \membersection{wxThread::This}\label{wxthreadthis}