我正在寻找某种“调试模式”或额外的代码,或钩子,或任何东西,从而我可以设置一个断点/日志/将被击中的东西,并允许我检查如果我的主要线程“自愿”用于I / O的块(或任何原因,真的),除了在循环结束时空闲.
在过去,我已经使用循环观察器观察了跑步循环的时钟周期,这对于查看问题很有价值,但是在你可以检查的时候,为了做一个好主意,为时已晚,因为您的代码已经在该循环的runloop中运行了.
我知道UIKit / AppKit执行的操作是仅主线程,这将导致I / O,并导致主线程阻塞,在一定程度上,它是无望的(例如,访问粘贴板似乎是一个潜在的阻止,仅限主线程的操作),但是一些东西比没有更好.
任何人有什么好的想法？似乎像有用的东西.在理想的情况下,您永远不会阻止主线程,而您的应用程序的代码在运行环境中处于活动状态,像这样的操作将非常有助于尽可能接近该目标.
解决方法
最重要的是重新解决问题.这是我想出的：
I want to be alerted to long periods of time spent in
syscalls/mach_msg_trap that are not legitimate idle time. “Legitimate
idle time” is defined as time spent in mach_msg_trap waiting for the
next event from the OS.
同样重要的是,我不在乎用户代码需要很长时间.这个问题很容易使用仪器的时间分析器工具进行诊断和了解.我想知道关于堵塞的时间.尽管您也可以使用Time Profiler来诊断被阻止的时间,但我发现用于此目的相当困难.同样,系统跟踪仪器对于这样的调查也是有用的,但是非常细小和复杂.我想要一些更简单的东西 – 更多地针对这个具体的任务.
看起来很明显,这里选择的工具是Dtrace.
我开始使用一个CFRunLoop观察者发射kcfRunLoopAfterWaiting和kcfRunLoopBeforeWaiting.对我的kcfRunLoopBeforeWaiting处理程序的调用将指示“合法空闲时间”的开始,并且kcfRunLoopAfterWaiting处理程序将是向我发出合法等待结束的信号.我将使用Dtrace pid提供程序来陷阱对这些函数的调用,作为排除合法空闲阻塞空闲的一种方法.
这种方法让我开始了,但最终证明是有缺陷的.最大的问题是许多AppKit操作是同步的,因为它们阻止了UI中的事件处理,但实际上在调用堆栈中旋转了RunLoop. RunLoop的这些旋转不是“合法的”空闲时间(为了我的目的),因为在此期间用户不能与UI进行交互.它们是有价值的,可以肯定的是,想象一下在后台线程上运行一个RunLoop面向I / O的runloop,但是当主线程发生这种情况时,UI仍然被阻止.例如,我将以下代码放入IBAction并从一个按钮触发：
NSMutableURLRequest *req = [NSMutableURLRequest requestWithURL: [NSURL URLWithString: @"http://www.google.com/"]
cachePolicy: NSURLRequestReloadIgnoringCacheData
timeoutInterval: 60.0];
NSURLResponse* response = nil;
NSError* err = nil;
[NSURLConnection sendSynchronousRequest: req returningResponse: &response error: &err];
该代码不会阻止RunLoop旋转 – AppKit在sendSynchronousRequest：…调用中为您旋转 – 但它确实阻止用户与UI交互,直到它返回.这不是我的“合法闲置”,所以我需要一种方法来整理哪些空闲的东西. (CFRunLoopObserver方法也有缺陷,因为它需要修改代码,我的最终解决方案不会.)
我决定将我的UI /主线程模型化为状态机.在任何时候都处于三种状态之一：LEGIT_IDLE,RUNNING或BLOCKED,并且将在程序执行之间在这些状态之间来回切换.我需要提出Dtrace探测器,这样可以让我捕获(因此测量)这些转换.我实施的最终状态机比这三个状态要复杂得多,但这是20,000英尺的视图.
如上所述,从不良空闲中排除合法空闲并不简单,因为这两种情况最终都在mach_msg_trap()和__CFRunLoopRun中.我在调用堆栈中找不到一个简单的工件,我可以使用它来可靠地区分差异;看来,对一个功能的简单探测不会帮助我.我最终使用调试器来查看堆栈的状态,这些状态在合法空闲和不良空闲的各种情况下.我确定在合法闲置期间,我(看起来可靠)看到一个这样的调用堆栈：
#0 in mach_msg #1 in __CFRunLoopServiceMachPort #2 in __CFRunLoopRun #3 in CFRunLoopRunSpecific #4 in RunCurrentEventLoopInMode #5 in ReceiveNextEventCommon #6 in BlockUntilNextEventMatchingListInMode #7 in _DPSNextEvent #8 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] #9 in -[NSApplication run] #10 in NSApplicationMain #11 in main
所以我努力建立一堆嵌套/链接的pid探测器,当我到达并随后离开这个状态时,它将建立起来.不幸的是,无论什么原因,Dtrace的pid提供者似乎无法普遍检测所有任意符号的输入和返回.具体来说,我无法在pid000上找到探针：*：__ CFRunLoopServiceMachPort：return或on pid000：*：_ DPSNextEvent：return to work.细节并不重要,但是通过观察各种其他事情,跟踪某些状态,当我进入并离开合法闲置状态时,我能够(再次看似可靠地)建立起来.
然后我不得不确定探测器来告诉RUNNING和BLOCKED之间的区别.那有点简单最后,我选择考虑BSD系统调用(使用Dtrace的系统调用探针),并调用mach_msg_trap()(使用pid探针),而不是在合法空闲时段发生的BLOCKED. (我看过Dtrace的mach_trap探测器,但似乎没有做我想要的,所以我回到使用pid探针.)
最初,我与Dtrace sched提供商进行了一些额外的工作,以实际测量实际的阻塞时间(即我的线程被调度程序暂停的时间),但这增加了相当大的复杂性,我最终想到了自己：“如果我在内核中,如果线程实际上是睡着了,该怎么办？对用户来说都是一样的：它被阻止了.所以最后的方法只是在(syscalls || mach_msg_trap())&&&& ！authorized_idle并且调用阻塞的时间.
在这一点上,捕获长持续时间的单个内核调用(例如调用sleep(5))变得微不足道.然而,更多的UI线程延迟来自于通过多次调用进入内核的许多小延迟(想到数百个对read()或select()的调用),所以我认为,当希望将SOME调用堆栈转储到事件循环的单次通过中的系统调用或mach_msg_trap时间的总量超出了一定的阈值.我结束了在各州设置各种计时器和记录累计时间,范围在州机器的各个州,当我们碰巧从BLOCKED状态转移出来时倾倒警报,并且已经超过了一个阈值.这种方法显然会产生可能会被误解的数据,或者可能是一个完整的红色鲱鱼(即一些随机的,相对较快的系统调用,恰好将我们超过了警戒阈值),但我觉得它比没有更好.
最后,Dtrace脚本最终将状态机保存在D变量中,并使用所描述的探针来跟踪状态之间的转换,并使我有机会在状态机转换状态时进行操作(如打印警报)在某些条件下.我玩了一个有创意的示例应用程序,做一堆磁盘I / O,网络I / O和调用sleep(),并能够抓住所有这三种情况,而不会分散与合法等待的数据.这正是我正在寻找的.
这个解决方案显然相当脆弱,几乎在各方面都非常糟糕. :)对我或任何其他人来说,这可能或不是有用的,但这是一个有趣的练习,所以我以为我会分享这个故事,以及由此产生的Dtrace脚本.也许别人会发现它很有用.我也必须承认在编写Dtrace脚本方面是一个相对的n00b,所以我确信我做了一百万个错误.请享用！
它太大了,不能排队,所以它由@Catfish_Man托管在这里：MainThreadBlocking.d
