swift - 在 Cocoa macos 应用程序中捕获 SIGINT

Question

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

func applicationWillTerminate(_ aNotification: Notification) {

}

但是，Ctrl + C，SIGINT，永远不会在这里被捕获。在互联网上阅读，表明此功能不能保证执行，尤其是当应用程序进入后台时。

我可以在 app delegate 中做什么来捕捉 SIGINT？或者是否有其他地方可以捕捉中断，以便我可以适本地关闭资源？

Answer 1

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

Technical Note TN2050: Observing Process Lifetimes Without Polling是一个不同的主题，但说明了该技术。在那里，Apple 以这种方式描述了 Charles 的警告:

Listening for a signal can be tricky because of the wacky execution environment associated with signal handlers. Specifically, if you install a signal handler (using signal or sigaction), you must be very careful about what you do in that handler. Very few functions are safe to call from a signal handler. For example, it is not safe to allocate memory using malloc!

The functions that are safe from a signal handler (the async-signal safe functions) are listed on the sigaction man page.

In most cases you must take extra steps to redirect incoming signals to a more sensible environment.

我从那里获取了代码插图并对其进行了修改以处理 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 风格的信号处理程序相比，您将拥有更大的灵 active 。

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