时间戳

首页 > 解决方案 > 在 Cocoa macos 应用程序中捕获 SIGINT

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

问题描述

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

func applicationWillTerminate(_ aNotification: Notification) {

}

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

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

标签： swiftmacos

解决方案

查尔斯的回答是正确的，但他的警告（“确保只从处理程序中调用可重入函数”）是一个极端的限制。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 队列，但我不完全确定如果该进程已经运行了许多失控线程，该处理程序是否会运行。也就是说，实际上在高优先级队列上运行的任务将优先于低优先级线程或队列，但启动新任务可能不会。我不确定。

推荐阅读