objective-c 如何找出 mach_msg_trap 等待什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1488601/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to find out what mach_msg_trap waits for?
提问by PeyloW
I a profiling my iPhone application on target, and according to Instruments 65% of the time is spent in mach_msg_trap.
我在目标上分析了我的 iPhone 应用程序，根据 Instruments，65% 的时间都花在mach_msg_trap.
I have a background thread that runs-forever and send results back to the main thread using performSelectorOnMainThread:withObject:waitUntilDone:, aproximately every 2 seconds. I am not waiting until done.
我有一个永远运行的后台线程，并使用 将结果发送回主线程performSelectorOnMainThread:withObject:waitUntilDone:，大约每 2 秒一次。我不会等到完成。
采纳答案by PeyloW
Turn out my app is not actually spending 65% of it's time in the mach_msg_trapfunction. It was a configuration error in Instruments on my part.
原来我的应用程序实际上并没有在mach_msg_trap函数中花费 65% 的时间。就我而言，这是 Instruments 中的配置错误。
The Sampler tool defaults to All Sample Counts, this will measure all threads regardless of their state.
Sampler 工具默认为All Sample Counts，这将测量所有线程，而不管它们的状态。
Instead switch to Running Sample Timesthat will reflect the current actual workload. Screenshot of Instruments http://developer.apple.com/library/mac/qa/qa2009/images/qa1619_running_sample_times.png
而是切换到将反映当前实际工作负载的运行采样时间。 仪器截图 http://developer.apple.com/library/mac/qa/qa2009/images/qa1619_running_sample_times.png
回答by nall
If you're not expecting your main thread to be doing anything other than waiting on this background thread (or waiting for user input) there's nothing to be concerned about -- your application simply has nothing to do most of the time.
如果你不希望你的主线程除了等待这个后台线程（或等待用户输入）之外做任何事情，那么没有什么可担心的——你的应用程序在大多数时间里根本没有任何事情可做。
If you're expecting the main thread to be actively doing something else, please update your question to describe that. In this case, you might want to look at the full call stacks to mach_msg_trap as it's often at the bottom of a call stack where the actual time-waster is further up.
如果您希望主线程积极做其他事情，请更新您的问题来描述这一点。在这种情况下，您可能需要查看对 mach_msg_trap 的完整调用堆栈，因为它通常位于调用堆栈的底部，实际浪费时间的位置更远。
