小编Jan*_*Jan的帖子

如何知道应用支持哪种UTI,将文件发送到其他应用程序？假设文件没有文件扩展名,但我碰巧知道文件的UTI.

我尝试了以下方法:

// target is a NSURL with the location of the extension less file on the system
// knownUTI is a NSString containing the UTI of the file 
    UIDocumentInteractionController* dic = [UIDocumentInteractionController interactionControllerWithURL:target];  
    [dic retain];

    dic.delegate = self;
    dic.UTI = knownUTI; 
    [dic presentOpenInMenuFromRect:CGRectZero inView:superController.view animated:YES]

它显示了受支持的应用程序,但是,如果我选择它,它将不会切换应用程序.代表打电话给

- (void)documentInteractionController:(UIDocumentInteractionController *)controller willBeginSendingToApplication:(NSString *)application

但

- (void)documentInteractionController:(UIDocumentInteractionController *)controller didEndSendingToApplication:(NSString *)application

永远不会被调用,应用程序永远不会切换.

目标App在以下内容中导出其UTI:

    <key>CFBundleDocumentTypes</key>
    <array>
        <dict>
            <key>CFBundleTypeIconFiles</key>
            <array/>
            <key>CFBundleTypeName</key>
            <string>Migration DocType</string>
            <key>CFBundleTypeRol</key>
            <string>Shell</string>
            <key>LSHandlerRank</key>
            <string>Owner</string>
            <key>LSItemContentTypes</key>
            <array>
                <string>com.mycomp.customstring</string>
            </array>
        </dict>
    </array>

...

<key>UTExportedTypeDeclarations</key> …

当我与一些同事讨论 uni- 和 SMP 内核中自旋锁的行为时，我们深入研究了代码，发现了一条令我们非常惊讶的行，我们无法弄清楚为什么会这样。

简短的 calltrace 来显示我们来自哪里：

spin_lock 调用 raw_spin_lock，

raw_spin_lock 调用 _raw_spin_lock，和

在单处理器系统上，_raw_spin_lock #defined 为 __LOCK

__LOCK 是一个定义：

#define __LOCK(lock) \
  do { preempt_disable(); ___LOCK(lock); } while (0)

到现在为止还挺好。我们通过增加内核任务的锁定计数器来禁用抢占。我认为这样做是为了提高性能：因为你不应该持有一个自旋锁超过很短的时间，你应该只是完成你的关键部分而不是被中断，并且可能有另一个任务在等待你的时候旋转它的调度片段结束。

然而，现在我们终于来回答我的问题了。对应的解锁码如下所示：

#define __UNLOCK(lock) \
  do { preempt_enable(); ___UNLOCK(lock); } while (0)

为什么要在 ___UNLOCK 之前调用 preempt_enable()？这对我们来说似乎很不直观，因为您可能会在调用 preempt_enable 后立即被抢占，而没有机会释放您的自旋锁。感觉这使得整个 preempt_disable/preempt_enable 逻辑有些无效，特别是因为 preempt_disable 在其调用期间专门检查锁计数器是否再次为 0，然后调用调度程序。在我们看来，首先释放锁，然后减少锁计数器并因此可能再次启用调度会更有意义。

我们缺少什么？在 ___UNLOCK 之前调用 preempt_enable 而不是相反的想法是什么？