The proxy class for peerconnection is defined in the Trunk\talk\app\webrtc\peerconnectionproxy.h file, class Peerconnection:public Peerconnectioninterface, while # define BEGIN_PROXY_MAP (c) \
Class C # #Proxy: Public C # #Interface所以BEGIN_PROXY_MAP (peerconnection) expands to
class peerconnection : public peerconnectioninterface. So the talk\examples\peerconnection\client\conductor.cc file in the peerconnection example conductor::i The Nitializepeerconnection () function calls the Peerconnectionfactory::createpeerconnection function, which passes the Signaling_thread_ The Peerconnectionfactory::createpeerconnection_s object calls the Peerconnectionproxy::create function in the function, trunk\talk\app\webrtc\ The Create function of the proxy class is defined in the Proxy.h file, in the form of Testproxy::create (thread*, testinterface*). So the above peerconnectionfactory::createpeerconnection_s function calls Peerconnectionproxy:: Create creates a Peerconnectionproxy pointer object, and this pointer object is eventually returned to trunk\talk\examples\peerconnection\client\ Member variables in the Conductor.h file TALK_BASE::SCOPED_REFPTR<WEBRTC::P eerconnectioninterface> peer_connection_; The functions that are called later by Peer_connection_ are actually peerconnectionproxy::xxx. because Peerconnectionproxy encapsulates a Talk_base::thread* owner_thread_ object and a peerconnection pointer object, When a function is called through PEERCONNECTIONPROXY::XXX, Peerconnection::xxx is called through its member variable pointer (thread pointer), where the thread pointer is trunk\talk\app\webrtc\ PeerconnectionfactoryThe member variable talk_base::thread* signaling_thread_; of the Peerconnectionfactory class in the. h file. In the trunk\talk\base\win32socketserver.cc file, the CMS in the win32socketserver::wait function is not understood to call GetMessage 0 o'clock (&msg, NULL, s_wm_wakeup_id, s_wm_wakeup_id), and the processing of the message s_wm_wakeup_id in the Win32socketserver::messagewindow::onmessage function. See for a long while also did not understand, had to in win32socketserver::wait and win32socketserver::wakeup add outputdebugprintf to output related information. created two talk_base::thread threads Signaling_thread_ and Worker_thread_ in the Peerconnectionfactory constructor. When you double-click the call-to-end, the main thread calls the Signaling_thread_ threaded pointer object to send the Msg_init_factory message. The peerconnectionfactory::initialize_s function then responds to the message, resetting its member variable in the function Talk_base::scoped_ptr<cricket::channelmanager > channel_manager_, and pass the Worker_thread_ pointer object to the member, then call the Channelmanager::init initialization function, and call ChannelManager: Setaudiooptions, called by the Worker_thread_ pointer in this function thread::invoke the template function. And because its response function channelmanager::setaudiooptions_w is executed in the SIGNALING_THREAD_ thread message response, it is not executed to Win32socketserver:: The wait and Win32socketserver::wakeup functions. also in response to the peerconnectionfactory::initial of msg_init_factory messagesIn the ize_s function, the function calls the Channelmanager::init, and when the above Channelmanager::setaudiooptions_w function is executed, ChannelManager is called: The Setcapturedevice function, which is similar to the Channelmanager::setaudiooptions function, also uses the Worker_thread_ pointer as a template function thread::i Nvoke Call execution Channelmanager::setcapturedevice_w. The second message sent by the &NBSP;SIGNALING_THREAD_ thread pointer is msg_create_peerconnection, and the third message is Msg_create_audiosource. The third message is Msg_create_audiosource, and the fourth message is Msg_create_videosource, and the two messages are sent after double-clicking on the call peer, calling Conductor::i The Nitializepeerconnection () function then calls the Conductor::addstreams () function, which in turn calls Peerconnectionfactory::createaudiosource () in the function and the Peerconnectionfactory::createvideosource () function is sent. add outputdebugprintf to the win32socketserver::wait and Win32socketserver::wakeup functions to output relevant information when called in the main thread signaling_ Thread_->send, enter to Thread::send discovery, first call Current_thread->socketserver ()->wait (Kforever, false); Blocks the current thread, the main thread, wait, and then signaling_thread_ the thread's message response loop back in response to the message sent by Signaling_thread_->send, in thread:: ProcessMessages called Messagequeue::get, and then in this function to call thread::receivesends, in this function in response to the message sent by Signaling_thread_->send , call SMsg.thread->socketserver ()->wakeup (), which is the win32socketserver::wakeup of the main thread, so that the main thread in the Thread::send function calls the Current_ Thread->socketserver ()->wait (Kforever, false), blocked, can continue execution now, and then the last statement of Thread::send is executed in the main thread Current_ Thread->socketserver ()->wakeup (); Win32socketserver::wakeup. call Current_thread->socketserver () in Thread::send when Signaling_thread_->send is called next time in the main thread->wait (Kforever, false), the main thread is not blocked, but the message sent by Signaling_thread_->send has not been responded to, and the ready variable is false until Signaling_thread_ The thread's message response loop assigns the ready value to True after calling Thread::receivesends () to respond to the message. So the Current_thread->socketserver ()->wait (Kforever, false) is called the second time in the while loop in the Thread::send function, and this time it blocks the main thread.
Based on the analysis of the above two paragraphs, when calling Signaling_thread_->send in the main thread, the order in which messages are printed in the win32socketserver::wait and Win32socketserver::wakeup functions is, The first call prints wait, then prints two times wakeup, and when you call Signaling_thread_->send later, it prints two wait and then prints two times wakeup. When the latter responds to Signaling_thread_->send, the first print wait is actually equivalent to consuming the thread when sending the message in the previous execution signaling_thread_->send: The last statement in the Send function is Current_thread->socketserver ()->wakeup ();. The second wait is the main thread that is blocking the current one. When execution Signaling_thread_->send sends a message it prints two times wakeup, where the second time is the last statement in the Thread::send function Current_thread->socketserver (), WakeUp (); The first is the Smsg.thread->socketserver () in the Thread::receivesends function executed by the SIGNALING_THREAD_ thread's message response loop type->wakeup ();。 When responding to the fourth message Msg_create_videosource, the Videocapturer::setcapturestate function is called when the message is heard, and in the function the main thread is the talk_base in the main function: Win32thread W32_thread; to invoke Thread_->post. Because the virtual function actually executes the MessageQueue::P the OST function, the function calls Ss_->wakeup (), which is win32socketserver::wakeup, and then because of the thread::send in the while loop, The response to this message is not complete, so wait is continued.
When the
responds to the fourth message Msg_create_videosource, peerconnectionfactory::createvideosource_s calls VideoSource: The CREATE function then calls Videosource::initialize, which in turn calls Channelmanager::startvideocapture, which in this function is passed worker_thread_-> Invoke to execute the capturemanager::startvideocapture when the Capturemanager is executed in the WORKER_THREAD_ thread message response loop:: The videocapturer::setcapturestate is eventually called in Startvideocapture, and the function is Talk_base::win32thread w32_thread through the main thread, which is the main function; To call Thread_->post to send a msg_state_change message.
Return to the Thread::send function, take the main thread call Signaling_thread_->send send a message as an example, detects that the sending thread is this is not the current thread (main thread), the message is called Sendlist_.push_ Back (smsg); save it and then start waiting for the message to respond (wait for a reply) when calling ss_->wakeup (); (That is, physicalsocketserver : WakeUp), the message response loop of the Signaling_thread_ thread responds to the message. So it is possible that the message response loop that has signaling_thread_ the thread has already responded to the message and called Smsg.thread->socketserver ()->wakeup (), and then the CPU then executes the thread:: Ss_->wakeup () in the Send function, followed by a while loop, i.e. Current_thread->socketserver ()->wait (Kforever, false);. Of course this time will return immediately, without blocking the getmessage in the Win32socketserver::wait function (&msg, null, s_wm_wakeup_id, s_wm_ WAKEUP_ID), and executes the last statement of the Thread::send function Current_thread->socketserver ()->wakeup ();. These are obtained by printing the relevant information in the WIN32SOCKETSERVER::WAIT and Win32socketserver::wakeup functions. when you double-click the call to end, call Signaling_thread_->send in the main thread to send the message in turn msg_init_factory, Msg_create_peerconnection, Msg_ Create_audiosource and Msg_create_videosource. It then resumes execution in the Conductor::addstreams function and continues to call Signaling_thread_->send to send the message. Call C in the Conductor::connecttopeer function as shown in: The Onductor::initializepeerconnection function, in turn, calls Conductor::addstreams (), in conductor:: Peerconnectionproxy::createoffer is called when the Connecttopeer function finishes executing initializepeerconnection. Because Peerconnectionproxy is associated with Signaling_thread_, Signaling_thread_->send is also called to send a message. After this step executes, the call to execute the Ss_->pump () in the Win32socketserver::messagewindow::onmessage function is started, (i.e. Win32socketserver::P UMP ()), Finally, MessageQueue is called in the function: the main thread is called before the videocapturer::onmessage response is executed:D Ispatch (that is, talk_base::win32thread w32_thread; ) sends a MSG_STATE_CHANGE message. Why is the Peerconnectionproxy::createoffer executed before it can be executed to Win32socketserver::messagewindow::o The inside of the Nmessage function executes Ss_->pump (); This is because the first message msg_init_factory from the call Signaling_thread_->send, the main thread has been executing the code in the following form, That is, the main thread is called by calling the GetMessage (&msg, null, s_wm_wakeup_id, s_wm_wakeup_id) in the win32socketserver::wait function; To block, and then Win32socketserver::wakeup () (Signaling_thread_ threads and main thread) executes PostMessage (Wnd_.handle (), s_wm_wakeup_id, &NBSP;0,&NBSP;0); Wake up. The main thread has been responding to double-clicking the call-to-end event, that is, executing the conductor::connecttopeer, and then having completed the function has the opportunity to respond to the main thread Msg_state_chanGE message, which is a message queue that is post to the main thread during the execution of the Conductor::connecttopeer function through the main thread.
After the execution of Peerconnectionproxy::createoffer, due to the last call in Thread::send Current_thread->socketserver () WakeUp ();, the function is Win32socketserver::wakeup (), this function PostMessage (Wnd_.handle (), s_wm_wakeup_id, 0, 0); , so the member variable messagewindow wnd_; of the Win32socketserver object created in the main thread will receive the message s_wm_wakeup_id, which should actually be the main thread receiving the message because the main thread (that is, Talk_base:: win32thread w32_thread;), the Win32socketserver object and its member variable Messagewindow wnd_ are created, based on MSDN's explanation of the PostMessage function " places (posts) a message in the message queue associated with the thread that created the specified window and returns Without waiting for the thread to process the message. ". So the main thread receives the S_WM_WAKEUP_ID message in the message queue. This shows the main thread through the win32socketserver::wait function of the getmessage (&msg, null, s_wm_wakeup_id, s_wm_wakeup_id); , while the Signaling_thread_ thread passes through the Win32socketserver::wakeup function in PostMessage (Wnd_.handle (), s_wm_wakeup_id, 0, &NBSP;0); to wake up, because the function getmessage is gets a message from the calling thread's message queue and places it in the specified structure. GetMessage does not receive messages belonging to other threads or applications. ", but you can understand the thread wakes the main thread by PostMessage's MSDN annotations.
And the Conductor::connecttopeer function calls the main thread to send the Msg_state_change message, which wakes up the wait for a main thread, but on the main thread through thread:: The while loop in the Send function determines that the current message is not responding and will continue to block, that is, the main thread consumes a wake-up call, so that when Thread::send executes to the end, that is, the current message is sent by the process to wake up again after the main thread (or called the current thread, Because this is the main thread as an example). Take a look at the last comment of the Thread::send function in detail. the Conductor::onmessagefrompeer function is executed after double-clicking on the call Peer, and then the signaling_thread_->send is also called to send the message, as shown in Where peerconnectionproxy::addicecandidate may be executed multiple times. the Conductor::onmessagefrompeer function is executed after double-clicking on the call Peer, and the signaling_thread_->send is also called to send the message. Print Ss_->pump () in the Win32socketserver::messagewindow::onmessage function at the same time, and find each call Peerconnectionproxy:: After the addicecandidate is executed once, the output ss_->pump () will be printed, and after videotrackproxy::addrenderer, it is possible that the printout may not print out. Other there is no more printing output ss_->pump (); when executing the Conductor::onmessagefrompeer function, the first call to Signaling_thread_->send to send a message is in Peerconnectionproxy:: Setremotedescription, the message new_stream_added sent to the main thread via PostThreadMessage, and then the main thread passes conductor:: Uithreadcallback the message should be sent two times by calling Signaling_thread_->send. Now, in the win32socketserver::wait function of the trunk\talk\base\win32socketserver.cc file,GetMessage (&msg, NULL, s_wm_wakeup_id, s_wm_wakeup_id), and the Win32socketserver::messagewindow::onmessage function The understanding of the _WAKEUP_ID message response is over.
Libjingle The message response of the main thread
