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 9 users

Issue metadata

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

Issue description

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: ----

Comment 14 by, Mar 14 (5 days ago)

I see quite similar issue with main thread freezes on PeerConnection.close method
and callstack points to PhysicalSocketServer::WaitSelect

Screen Shot 2018-03-14 at 11.18.15 AM.png
313 KB View Download

Sign in to add a comment