在 Cocoa macos 应用程序中捕获 SIGINT

Question

我正在尝试为为 MacOS 制作的 UI 应用程序捕获 SIGINT。 在应用程序委托类中，我看到以下方法：

func applicationWillTerminate(_ aNotification: Notification) {

}

但是， Ctrl + C SIGINT 永远不会被困在这里。 在互联网上阅读，表明此功能不能保证执行，特别是如果应用程序进入后台。

我可以在应用程序委托中做什么来捕获 SIGINT？ 或者是否有其他地方可以捕获中断以便我可以适当地关闭资源？

Answer 1

Charles 的回答是正确的，但他的警告（“确保只从处理程序中调用可重入函数”）是一个极端的限制。 可以使用kqueue和CFFileDescriptor将信号的处理重定向到更安全的环境。

技术说明 TN2050：在没有轮询的情况下观察进程生命周期是一个不同的主题，但说明了该技术。 在那里，Apple 以这种方式描述了 Charles 的警告：

由于与信号处理程序相关的古怪执行环境，监听信号可能会很棘手。 具体来说，如果您安装了一个信号处理程序（使用signal或sigaction ），您必须非常小心您在该处理程序中所做的事情。 很少有函数可以安全地从信号处理程序调用。 例如，使用malloc分配内存是不安全的！

信号处理程序安全的函数（异步信号安全函数）列在sigaction 手册页上。

在大多数情况下，您必须采取额外的步骤将传入的信号重定向到更合理的环境。

我从那里获取了代码说明并对其进行了修改以处理SIGINT 。 对不起，这是Objective-C。 这是一次性设置代码：

// Ignore SIGINT so it doesn't terminate the process.

signal(SIGINT, SIG_IGN);

// Create the kqueue and set it up to watch for SIGINT. Use the 
// EV_RECEIPT flag to ensure that we get what we expect.

int kq = kqueue();

struct kevent changes;
EV_SET(&changes, SIGINT, EVFILT_SIGNAL, EV_ADD | EV_RECEIPT, NOTE_EXIT, 0, NULL);
(void) kevent(kq, &changes, 1, &changes, 1, NULL);

// Wrap the kqueue in a CFFileDescriptor. Then create a run-loop source
// from the CFFileDescriptor and add that to the runloop.

CFFileDescriptorContext context = { 0, self, NULL, NULL, NULL };
CFFileDescriptorRef kqRef = CFFileDescriptorCreate(NULL, kq, true, sigint_handler, &context);
CFRunLoopSourceRef rls = CFFileDescriptorCreateRunLoopSource(NULL, kqRef, 0);
CFRunLoopAddSource(CFRunLoopGetCurrent(), rls, kCFRunLoopDefaultMode);
CFRelease(rls);

CFFileDescriptorEnableCallBacks(kqRef, kCFFileDescriptorReadCallBack);
CFRelease(kqRef);

以下是您将如何实现sigint_handler回调：

static void sigint_handler(CFFileDescriptorRef f,  CFOptionFlags callBackTypes, void *info)
{
    struct kevent event;

    (void) kevent(CFFileDescriptorGetNativeDescriptor(f), NULL, 0, &event, 1, NULL);
    CFFileDescriptorEnableCallBacks(f, kCFFileDescriptorReadCallBack);

    // You've been notified!
}

请注意，此技术要求您在线程上运行设置代码，只要您对处理SIGINT （可能是应用程序的生命周期）和服务/运行其运行循环感兴趣，该线程就会一直存在。 系统为自身目的创建的线程（例如为 Grand Central Dispatch 队列提供服务的线程）不适合此目的。

应用程序的主线程将工作，您可以使用它。 但是，如果主线程锁定或变得无响应，则它不会为其运行循环提供服务，并且不会调用SIGINT处理程序。 由于SIGINT经常用于中断这样一个卡住的进程，主线程可能不适合。

因此，您可能希望生成自己的线程来监视此信号。 它不应该做任何其他事情，因为其他任何事情也可能导致它卡住。 但是，即使在那里，也存在问题。 您的处理程序函数将在您的后台线程上调用，主线程可能仍被锁定。 系统库中有很多只用于主线程的东西，您将无法执行任何操作。 但是与 POSIX 样式的信号处理程序相比，您将拥有更大的灵活性。

我应该补充一点，GCD 的调度源也可以监视 UNIX 信号并且更容易使用，尤其是来自 Swift。 但是，它们不会预先创建专用线程来运行处理程序。 处理程序将被提交到队列。 现在，您可以指定一个高优先级/高 QOS 队列，但我不完全确定如果进程已经运行了许多失控线程，处理程序是否会运行。 也就是说，实际在高优先级队列上运行的任务将优先于低优先级线程或队列，但启动新任务可能不会。 我不知道。

Answer 2

您可以通过sigaction()函数执行此操作：

import Foundation

let handler: @convention(c) (Int32) -> () = { sig in
    // handle the signal somehow
}

var action = sigaction(__sigaction_u: unsafeBitCast(handler, to: __sigaction_u.self),
                        sa_mask: 0,
                        sa_flags: 0)

sigaction(SIGINT, &action, nil)

确保只从处理程序中调用可重入函数。

Answer 3

虽然我不敢与上面的好答案竞争，但我认为有一些重要的事情可以说可以大大简化解决方案。

我认为您的问题混合了两个截然不同的 MacOS 程序生命周期管理级别。

确实，您可以在 Mac 上运行简单的 posix 样式的可执行文件 - 但 Mac Cocoa 应用程序不是带有“附加 UI”的 posix 应用程序。 Mac 应用程序依赖于一个非常冗长、完整且功能丰富的生命周期机制，它允许比 posix 进程更多的功能——从状态保存和恢复（当被杀死/重新启动时）到自动启动以响应打开一个文件。 能源管理、处理计算机睡眠、后台和前台转换、附加到附近设备上的同一个应用程序、模式等。

此外——我看不出人们怎么能指望键盘上的“ctrl-C”到达 Cocoa（“UI”）应用程序，因为在这种情况下键盘快捷键完全不同，你不能运行“ UI”应用程序从终端/外壳同步。

现在，“中断”“卡住”或执行某项操作时间过长的 Cocoa 应用程序的正确方法是使用约定的command-preiod键组合，该组合仍被许多应用程序（Photoshop、视频编辑器、Finder等）很抱歉，我无法在 Apple 用户界面指南中找到此定义 - 也许它不再是标准的一部分。 但是，Ctrl-C 肯定不是！！！

您可以在您的应用程序中实现 Cmd-Period (⌘.)（即注册此高级“中断”操作，并优雅地处理它。

包装 Cocoa App 的 NSApplication 对象忽略 SIGINT 是有充分理由的！ 它完全脱离了上下文。