New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 8 users
Status: Available
Owner: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Sign in to add a comment
iOS: talk_base::Thread doesn't process messages if it is main thread
Reported by, Jul 4 2014 Back to list
What steps will reproduce the problem?
1. Create talk_base::Thread with talk_base::Thread::Current() on main thread
2. Path it to some object
3. When time comes try to call mainThread_->Post(this, MSG_MESSAGE_ID, NULL); from other thread

What is the expected result?
1. OnMessage() should be called for handler object with correct message id on main thread

What do you see instead?
1. Nothing happens. Messages are kept in queue and not processed. The next lldb printout shows that I have added 3 same messages already for different handlers:

(lldb) p msgq_
(talk_base::MessageList) $1 = size=3 {
  [0] = (phandler = 0x15aede04, message_id = 4, pdata = 0x00000000, ts_sensitive = 0)
  [1] = (phandler = 0x161a7004, message_id = 4, pdata = 0x00000000, ts_sensitive = 0)
  [2] = (phandler = 0x161c4404, message_id = 4, pdata = 0x00000000, ts_sensitive = 0)

What version of the product are you using? On what operating system?
I use webrtc revision 6081 on iOS7

Please provide any additional information below.

I have found and which might be related to this issue.

I have also found and tried this solution too: but MacCFSocketServer immediately asserts in Wait() for me.

If the thread is not a main thread everything works fine for me.

I would appreciate any thoughts on this since I really need to send callbacks to main thread.

Project Member Comment 1 by, Jul 7 2014
Have your tried AppRTCDemo on your iOS device? Does it work?
Comment 2 by, Jul 7 2014
No, I haven't tried. I don't use ObjC wrappers for webrtc provided in app/webrtc/objc and I don't use ninja for building.

I generate Xcode project files and build everything with Xcode. I almost don't use  ObjC wrappers with exception for a couple of high level objects so most of webrtc lives in c++ land. 

Until recently I used Grand Central Dispatch and blocks in bridge classes to make callbacks to main thread in ObjC land. Couple of days ago I have decided to start getting rid of bridge classes and use c++ API provided by talk_base::Thread and talk_base::MessageHandler to main thread directly.

signaling_thread = new talk_base::Thread();
from main thread: signaling_thread->Post(handler, Message_id);
OnMessage: do some work in signaling_thread and then bridge_->DeliverData();
DeliverData() {
  dispatch_async(get_main_queue, 0) {
    work to be done on main thread

What I want to achieve: 
signaling_thread = new talk_base::Thread();
main_thread = talk_base::Thread::Current();
from main thread: signaling_thread->Post(handler, Message_id, (some msgData with main thread));
OnMessage: do some work in signaling_thread and then msgData->main_thread->Post(handler, main_thread_message_id, someMsgData)

Project Member Comment 3 by, Jul 11 2014
@tkchin, do you have any comment on this?
Comment 4 by, Aug 4 2014
Recently I have started receiving hangups in main thread:

* thread #1: tid = 0x15ebb6, 0x3ba9d440 libsystem_kernel.dylib`__select + 20, queue = '', stop reason = signal SIGSTOP
    frame #0: 0x3ba9d440 libsystem_kernel.dylib`__select + 20
    frame #1: 0x00607340 MyApp`talk_base::PhysicalSocketServer::Wait(this=0x156a41b0, cmsWait=-1, process_io=false) + 624 at
    frame #2: 0x00625ab8 MyApp`talk_base::Thread::Send(this=0x156a3ef0, phandler=0x27dfc8e4, id=0, pdata=0x00000000) + 396 at
    frame #3: 0x00565798 MyApp`webrtc::MethodCall0<webrtc::PeerConnectionInterface, talk_base::scoped_refptr<webrtc::StreamCollectionInterface> >::Marshal(this=0x27dfc8e4, t=0x156a3ef0) + 64 at proxy.h:103
  * frame #4: 0x005610fa MyApp`webrtc::PeerConnectionProxy::local_streams(this=0x155f16c0) + 78 at peerconnectionproxy.h:38

I believe this is the same problem but now this basically hangs up the app if I call some proxy methods of PeerConnection from main thread.

Project Member Comment 5 by, Oct 16 2014
Could the problem be reproduced in original AppRTCDemo? And How?
Anyway, patch is always welcome.
Project Member Comment 6 by, Dec 16 2014
PhysicalSocketServer can't be used on the main thread. need to use CarbonSocketServer or the equivalent (Zeke, what do we use in AppRTCDemo?)
Project Member Comment 7 by, Dec 16 2014
Labels: Area-Network
Project Member Comment 8 by, Dec 19 2014
AppRTCDemo uses the default CreatePeerConnectionFactory() method, which defaults to creating new signaling / worker threads. See:

So callbacks don't occur on main thread and I haven't seen the issue in AppRTCDemo.
Project Member Comment 9 by, Jan 6 2015
Labels: EngTriaged
Status: Available
Might need to create some sort of CocoaSocketServer, but for now the guidance in #8 seems like the best solution.
Project Member Comment 10 by, May 19 2015
To a better owner.
Project Member Comment 11 by, May 19 2015
Bouncing it to pthatcher@ for now since this is network related. I don't know anything about SocketServer bits, but if we need something special to happen for iOS then I can take a look. 
Project Member Comment 12 by, Nov 8 2016
Labels: Pri-3
Project Member Comment 13 by, Dec 14 2016
Owner: ----
Sign in to add a comment