wxThread deletion
Regardless of whether it has terminated or not, you should call wxThread::Wait on a joinable thread to release its memory,
as outlined in Types of wxThreads. If you created a joinable thread on the heap, remember to delete it manually with the
delete operator or similar means as only detached threads handle this type of memory management.
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.
wxWidgets calls in secondary threads
All threads other then the "main application thread" (the one wxApp::OnInit or your main function runs in, for example) are considered
"secondary threads". These include all threads created by wxThread::Create or the corresponding constructors.
GUI calls, such as those to a wxWindow or wxBitmap are explicitly not safe at all in secondary threads and could end your application
prematurely. This is due to several reasons, including the underlying native API and the fact that wxThread does not run a GUI event
loop similar to other APIs as MFC.
A workaround that works on some wxWidgets ports is calling wxMutexGUIEnter before any GUI calls and then calling wxMutexGUILeave afterwords.
However, the recommended way is to simply process the GUI calls in the main thread through an event that is posted by either wxPostEvent
or wxEvtHandler::AddPendingEvent. This does not imply that calls to these classes are thread-safe, however, as most wxWidgets classes are
not thread-safe, including wxString.
wxThread::Kill()
wxThreadError Kill()
Immediately terminates the target thread. This function is dangerous and should be used with extreme care (and not used
at all whenever possible)! The resources allocated to the thread will not be freed and the state of the C runtime library
may become inconsistent. Use Delete() for detached threads or Wait() for joinable threads instead.
For detached threads Kill() will also delete the associated C++ object. However this will not happen for joinable threads
and this means that you will still have to delete the wxThread object yourself to avoid memory leaks. In neither case OnExit()
of the dying thread will be called, so no thread-specific cleanup will be performed.
This function can only be called from another thread context, i.e. a thread cannot kill itself.
It is also an error to call this function for a thread which is not running or paused (in the latter case, the thread will
be resumed first) -- if you do it, a wxTHREAD_NOT_RUNNING error will be returned.
wxWidgets' DDE-like protocol is a high-level protocol based on Windows DDE. There are two implementations of this DDE-like
protocol: one using real DDE running on Windows only, and another using TCP/IP (sockets) that runs on most platforms. Since
the API and virtually all of the behaviour is the same apart from the names of the classes, you should find it easy to switch
between the two implementations.
Notice that by including <wx/ipc.h> you may define convenient synonyms for the IPC classes: wxServer for either wxDDEServer
or wxTCPServer depending on whether DDE-based or socket-based implementation is used and the same thing for wxClient and wxConnection.
By default, the DDE implementation is used under Windows. DDE works within one computer only. If you want to use IPC between
different workstations you should define wxUSE_DDE_FOR_IPC as 0 before including this header -- this will force using TCP/IP
implementation even under Windows.
The following description refers to wx... but remember that the equivalent wxTCP... and wxDDE... classes can be used in much
the same way.
The following description refers to wx... but remember that the equivalent wxTCP... and wxDDE... classes can be used in much
the same way.
1. wxClient. This represents the client application, and is used only within a client program.
2. wxServer. This represents the server application, and is used only within a server program.
3. wxConnection. This represents the connection from the client to the server - both the client and the server use an instance
of this class, one per connection. Most DDE transactions operate on this object.
Messages between applications are usually identified by three variables: connection object, topic name and item name. A data
string is a fourth element of some messages. To create a connection (a conversation in Windows parlance), the client application
uses wxClient::MakeConnection to send a message to the server object, with a string service name to identify the server and a topic
name to identify the topic for the duration of the connection. Under Unix, the service name may be either an integer port identifier
in which case an Internet domain socket will be used for the communications or a valid file name (which shouldn't exist and will
be deleted afterwards) in which case a Unix domain socket is created.
The server then responds and either vetoes the connection or allows it. If allowed, both the server and client objects create
wxConnection objects which persist until the connection is closed. The connection object is then used for sending and receiving
subsequent messages between client and server - overriding virtual functions in your class derived from wxConnection allows you
to handle the DDE messages.
To create a working server, the programmer must:
1. Derive a class from wxConnection, providing handlers for various messages sent to the server side of a wxConnection (e.g. OnExecute,
OnRequest, OnPoke). Only the handlers actually required by the application need to be overridden.
2. Derive a class from wxServer, overriding OnAcceptConnection to accept or reject a connection on the basis of the topic argument.
This member must create and return an instance of the derived connection class if the connection is accepted.
3. Create an instance of your server object and call Create to activate it, giving it a service name.
To create a working client, the programmer must:
1. Derive a class from wxConnection, providing handlers for various messages sent to the client side of a wxConnection (e.g. OnAdvise).
Only the handlers actually required by the application need to be overridden.
2. Derive a class from wxClient, overriding OnMakeConnection to create and return an instance of the derived connection class.
3. Create an instance of your client object.
4. When appropriate, create a new connection using wxClient::MakeConnection, with arguments host name (processed in Unix only,
use 'localhost' for local computer), service name, and topic name for this connection. The client object will call OnMakeConnection
to create a connection object of the derived class if the connection is successful.
5. Use the wxConnection member functions to send messages to the server.
Data transfer
These are the ways that data can be transferred from one application to another. These are methods of wxConnection.
Execute: the client calls the server with a data string representing a command to be executed. This succeeds or fails, depending on
the server's willingness to answer. If the client wants to find the result of the Execute command other than success or failure, it
has to explicitly call Request.
Request: the client asks the server for a particular data string associated with a given item string. If the server is unwilling to
reply, the return value is NULL. Otherwise, the return value is a string (actually a pointer to the connection buffer, so it should
not be deallocated by the application).
Poke: The client sends a data string associated with an item string directly to the server. This succeeds or fails.
Advise: The client asks to be advised of any change in data associated with a particular item. If the server agrees, the server will
send an OnAdvise message to the client along with the item and data.
The default data type is wxCF_TEXT (ASCII text), and the default data size is the length of the null-terminated string. Windows-specific
data types could also be used on the PC.
Regardless of whether it has terminated or not, you should call wxThread::Wait on a joinable thread to release its memory,
as outlined in Types of wxThreads. If you created a joinable thread on the heap, remember to delete it manually with the
delete operator or similar means as only detached threads handle this type of memory management.
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.
wxWidgets calls in secondary threads
All threads other then the "main application thread" (the one wxApp::OnInit or your main function runs in, for example) are considered
"secondary threads". These include all threads created by wxThread::Create or the corresponding constructors.
GUI calls, such as those to a wxWindow or wxBitmap are explicitly not safe at all in secondary threads and could end your application
prematurely. This is due to several reasons, including the underlying native API and the fact that wxThread does not run a GUI event
loop similar to other APIs as MFC.
A workaround that works on some wxWidgets ports is calling wxMutexGUIEnter before any GUI calls and then calling wxMutexGUILeave afterwords.
However, the recommended way is to simply process the GUI calls in the main thread through an event that is posted by either wxPostEvent
or wxEvtHandler::AddPendingEvent. This does not imply that calls to these classes are thread-safe, however, as most wxWidgets classes are
not thread-safe, including wxString.
wxThread::Kill()
wxThreadError Kill()
Immediately terminates the target thread. This function is dangerous and should be used with extreme care (and not used
at all whenever possible)! The resources allocated to the thread will not be freed and the state of the C runtime library
may become inconsistent. Use Delete() for detached threads or Wait() for joinable threads instead.
For detached threads Kill() will also delete the associated C++ object. However this will not happen for joinable threads
and this means that you will still have to delete the wxThread object yourself to avoid memory leaks. In neither case OnExit()
of the dying thread will be called, so no thread-specific cleanup will be performed.
This function can only be called from another thread context, i.e. a thread cannot kill itself.
It is also an error to call this function for a thread which is not running or paused (in the latter case, the thread will
be resumed first) -- if you do it, a wxTHREAD_NOT_RUNNING error will be returned.
wxWidgets' DDE-like protocol is a high-level protocol based on Windows DDE. There are two implementations of this DDE-like
protocol: one using real DDE running on Windows only, and another using TCP/IP (sockets) that runs on most platforms. Since
the API and virtually all of the behaviour is the same apart from the names of the classes, you should find it easy to switch
between the two implementations.
Notice that by including <wx/ipc.h> you may define convenient synonyms for the IPC classes: wxServer for either wxDDEServer
or wxTCPServer depending on whether DDE-based or socket-based implementation is used and the same thing for wxClient and wxConnection.
By default, the DDE implementation is used under Windows. DDE works within one computer only. If you want to use IPC between
different workstations you should define wxUSE_DDE_FOR_IPC as 0 before including this header -- this will force using TCP/IP
implementation even under Windows.
The following description refers to wx... but remember that the equivalent wxTCP... and wxDDE... classes can be used in much
the same way.
The following description refers to wx... but remember that the equivalent wxTCP... and wxDDE... classes can be used in much
the same way.
1. wxClient. This represents the client application, and is used only within a client program.
2. wxServer. This represents the server application, and is used only within a server program.
3. wxConnection. This represents the connection from the client to the server - both the client and the server use an instance
of this class, one per connection. Most DDE transactions operate on this object.
Messages between applications are usually identified by three variables: connection object, topic name and item name. A data
string is a fourth element of some messages. To create a connection (a conversation in Windows parlance), the client application
uses wxClient::MakeConnection to send a message to the server object, with a string service name to identify the server and a topic
name to identify the topic for the duration of the connection. Under Unix, the service name may be either an integer port identifier
in which case an Internet domain socket will be used for the communications or a valid file name (which shouldn't exist and will
be deleted afterwards) in which case a Unix domain socket is created.
The server then responds and either vetoes the connection or allows it. If allowed, both the server and client objects create
wxConnection objects which persist until the connection is closed. The connection object is then used for sending and receiving
subsequent messages between client and server - overriding virtual functions in your class derived from wxConnection allows you
to handle the DDE messages.
To create a working server, the programmer must:
1. Derive a class from wxConnection, providing handlers for various messages sent to the server side of a wxConnection (e.g. OnExecute,
OnRequest, OnPoke). Only the handlers actually required by the application need to be overridden.
2. Derive a class from wxServer, overriding OnAcceptConnection to accept or reject a connection on the basis of the topic argument.
This member must create and return an instance of the derived connection class if the connection is accepted.
3. Create an instance of your server object and call Create to activate it, giving it a service name.
To create a working client, the programmer must:
1. Derive a class from wxConnection, providing handlers for various messages sent to the client side of a wxConnection (e.g. OnAdvise).
Only the handlers actually required by the application need to be overridden.
2. Derive a class from wxClient, overriding OnMakeConnection to create and return an instance of the derived connection class.
3. Create an instance of your client object.
4. When appropriate, create a new connection using wxClient::MakeConnection, with arguments host name (processed in Unix only,
use 'localhost' for local computer), service name, and topic name for this connection. The client object will call OnMakeConnection
to create a connection object of the derived class if the connection is successful.
5. Use the wxConnection member functions to send messages to the server.
Data transfer
These are the ways that data can be transferred from one application to another. These are methods of wxConnection.
Execute: the client calls the server with a data string representing a command to be executed. This succeeds or fails, depending on
the server's willingness to answer. If the client wants to find the result of the Execute command other than success or failure, it
has to explicitly call Request.
Request: the client asks the server for a particular data string associated with a given item string. If the server is unwilling to
reply, the return value is NULL. Otherwise, the return value is a string (actually a pointer to the connection buffer, so it should
not be deallocated by the application).
Poke: The client sends a data string associated with an item string directly to the server. This succeeds or fails.
Advise: The client asks to be advised of any change in data associated with a particular item. If the server agrees, the server will
send an OnAdvise message to the client along with the item and data.
The default data type is wxCF_TEXT (ASCII text), and the default data size is the length of the null-terminated string. Windows-specific
data types could also be used on the PC.
扫一扫
669
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
