Today is a work day. The last friday is exchanged with today owing changing the carpet.
These days I did not watch the Olympic Game. However, China team have gotten 46 gloden medals. Good!
Types of wxThreads
There are two types of threads in wxWidgets: detached and joinable, modeled after the the POSIX thread API. This is different
from the Win32 API where all threads are joinable.
By default wxThreads in wxWidgets use the detached behavior. Detached threads delete themselves once they have completed, either
by themselves when they complete processing or through a call to wxThread::Delete, and thus must be created on the heap (through
the new operator, for example). Conversely, joinable threads do not delete themselves when they are done processing and as such
are safe to create on the stack. Joinable threads also provide the ability for one to get value it returned from wxThread::Entry
through wxThread::Wait.
You shouldn't hurry to create all the threads joinable, however, because this has a disadvantage as well: you must Wait() for
a joinable thread or the system resources used by it will never be freed, and you also must delete the corresponding wxThread object
yourself if you did not create it on the stack. In contrast, detached threads are of the "fire-and-forget" kind: you only have to
start a detached thread and it will terminate and destroy itself.
wxThread deletion
Since detached threads delete themselves when they are finished processing, you should take care when calling a routine on one.
If you are certain the thread is still running and would like to end it, you may call wxThread::Delete to gracefully end it (which
implies that the thread will be deleted after that call to Delete()). It should be implied that you should never attempt to delete
a detached thread with the delete operator or similar means.
As mentioned, wxThread::Wait or wxThread::Delete attempts to gracefully terminate a joinable and detached thread, respectively.
It does this by waiting until the thread in question calls wxThread::TestDestroy or ends processing (returns from wxThread::Entry).
Obviously, if the thread does call TestDestroy() and does not end the calling thread will come to halt. This is why it is important
to call TestDestroy() in the Entry() routine of your threads as often as possible.
As a last resort you can end the thread immediately through wxThread::Kill. It is strongly recommended that you do not do this,
however, as it does not free the resources associated with the object (although the wxThread object of detached threads will still
be deleted) and could leave the C runtime library in an undefined state.
These days I did not watch the Olympic Game. However, China team have gotten 46 gloden medals. Good!
Types of wxThreads
There are two types of threads in wxWidgets: detached and joinable, modeled after the the POSIX thread API. This is different
from the Win32 API where all threads are joinable.
By default wxThreads in wxWidgets use the detached behavior. Detached threads delete themselves once they have completed, either
by themselves when they complete processing or through a call to wxThread::Delete, and thus must be created on the heap (through
the new operator, for example). Conversely, joinable threads do not delete themselves when they are done processing and as such
are safe to create on the stack. Joinable threads also provide the ability for one to get value it returned from wxThread::Entry
through wxThread::Wait.
You shouldn't hurry to create all the threads joinable, however, because this has a disadvantage as well: you must Wait() for
a joinable thread or the system resources used by it will never be freed, and you also must delete the corresponding wxThread object
yourself if you did not create it on the stack. In contrast, detached threads are of the "fire-and-forget" kind: you only have to
start a detached thread and it will terminate and destroy itself.
wxThread deletion
Since detached threads delete themselves when they are finished processing, you should take care when calling a routine on one.
If you are certain the thread is still running and would like to end it, you may call wxThread::Delete to gracefully end it (which
implies that the thread will be deleted after that call to Delete()). It should be implied that you should never attempt to delete
a detached thread with the delete operator or similar means.
As mentioned, wxThread::Wait or wxThread::Delete attempts to gracefully terminate a joinable and detached thread, respectively.
It does this by waiting until the thread in question calls wxThread::TestDestroy or ends processing (returns from wxThread::Entry).
Obviously, if the thread does call TestDestroy() and does not end the calling thread will come to halt. This is why it is important
to call TestDestroy() in the Entry() routine of your threads as often as possible.
As a last resort you can end the thread immediately through wxThread::Kill. It is strongly recommended that you do not do this,
however, as it does not free the resources associated with the object (although the wxThread object of detached threads will still
be deleted) and could leave the C runtime library in an undefined state.
扫一扫
1335
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
