问题描述
在建立/删除回调(例如kauth_unlisten_scope)和回调本身(在xnu代码库中，是的，我知道，它已过时)之间似乎没有同步.这就增加了跟踪/清除回调以及与扩展本身上的调用同步的负担.但这也是有问题的，因为有一个窗口可以指出线程已退出回调并实际上退出了扩展代码.
There doesn't appear to be synchronization between establishing/removing callbacks (e.g. kauth_unlisten_scope) and the callbacks themselves (in the xnu codebase, yes, I know, it's dated). This puts the burden of tracking/draining callbacks and synchronizing with calls on the extension itself. But this is problematic as well in that there is a window in noting that a thread has exited the callback AND actually returning out of the extension code.
是否有任何模式可以正确避免这场比赛?或者，Apple是否有任何文件表明他们已经正确同步了此文件?
Is there any pattern that gives a correct avoidance of this race? Or, is there any documentation from Apple that indicates they've synchronized this correctly?
推荐答案
据我所知，目前还没有100％可靠的方法来防止kauth回调注销竞争情况； API的设计不正确. Apple自己实现/推荐基于原子计数器的简单机制，您可以在 Kauth-O-Rama示例.在 KauthORama.c 源文件中搜索gActivationCount.线程在回调之前递增或递减之后运行代码的可能性仍然很小，但是我从未见过由此导致的崩溃.
As far as I'm aware there's no 100% reliable way of preventing kauth callback deregistration race conditions; the API is just badly designed. Apple themselves implement/recommend a simple atomic counter based mechanism, which you can see in the Kauth-O-Rama example. Search for gActivationCount in the KauthORama.c source file. There's still a small chance that a thread is running code before the increment or after the decrement in the callback, but I have never seen a crash caused by this.
这篇关于竞赛:在OSX中卸载kext期间的回调和删除回调的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！