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

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
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 you...@gmail.com, 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 https://code.google.com/p/libjingle/issues/detail?id=288 and https://code.google.com/p/webrtc/issues/detail?id=432 which might be related to this issue.

I have also found and tried this solution too: https://stackoverflow.com/questions/16598701/talk-basehttpserver-and-talk-basehttpclient-examples 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 braveyao@webrtc.org, Jul 7 2014

Owner: braveyao@webrtc.org
Have your tried AppRTCDemo on your iOS device? Does it work?

Comment 2 by you...@gmail.com, 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.

Working:
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 braveyao@webrtc.org, Jul 11 2014

Cc: tkchin@webrtc.org
@tkchin, do you have any comment on this?

Comment 4 by you...@gmail.com, Aug 4 2014

Recently I have started receiving hangups in main thread:

* thread #1: tid = 0x15ebb6, 0x3ba9d440 libsystem_kernel.dylib`__select + 20, queue = 'com.apple.root.high-priority', 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 physicalsocketserver.cc:1360
    frame #2: 0x00625ab8 MyApp`talk_base::Thread::Send(this=0x156a3ef0, phandler=0x27dfc8e4, id=0, pdata=0x00000000) + 396 at thread.cc:448
    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 braveyao@webrtc.org, Oct 16 2014

Could the problem be reproduced in original AppRTCDemo? And How?
Anyway, patch is always welcome.
Project Member

Comment 6 by juberti@webrtc.org, 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 juberti@webrtc.org, Dec 16 2014

Labels: Area-Network
Project Member

Comment 8 by tkchin@webrtc.org, Dec 19 2014

AppRTCDemo uses the default CreatePeerConnectionFactory() method, which defaults to creating new signaling / worker threads. See:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/source/talk/app/webrtc/peerconnectionfactory.cc&l=145

So callbacks don't occur on main thread and I haven't seen the issue in AppRTCDemo.
Project Member

Comment 9 by juberti@webrtc.org, Jan 6 2015

Labels: EngTriaged
Status: Available (was: NULL)
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 braveyao@webrtc.org, May 19 2015

Cc: -tkchin@webrtc.org juberti@webrtc.org braveyao@webrtc.org
Owner: tkchin@webrtc.org
To a better owner.
Project Member

Comment 11 by tkchin@webrtc.org, May 19 2015

Owner: pthatcher@webrtc.org
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 pthatcher@webrtc.org, Nov 8 2016

Labels: Pri-3
Project Member

Comment 13 by anatolid@webrtc.org, Dec 14 2016

Cc: pthatcher@webrtc.org
Owner: ----
I see quite similar issue with main thread freezes on PeerConnection.close method
and callstack points to PhysicalSocketServer::WaitSelect

https://bugs.chromium.org/p/webrtc/issues/detail?id=9015&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20ReleaseBlock%20Component%20Status%20Owner%20Summary&groupby=&sort=



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

Sign in to add a comment