构建仅背景COCOA应用程序作为启动守护程序的缺点？ [英] Drawbacks of building a background-only COCOA app as a launch daemon?

问题描述

在没有任何GUI的情况下构建仅限后台COCOA应用程序有任何缺点，并将其作为启动守护程序运行。这将使用：

Are there any drawbacks of building a background-only COCOA app without any GUI and run it as a launch daemon. This would use:

import <Foundation/Foundation.h>
import <AppKit/AppKit.h>
import <CoreData/CoreData.h>

使用它而不是构建一个objective-C命令行工具的主要优点是，隐式运行循环，其优点包括在应用程序完成启动或终止时定义良好的回调。这需要在命令行应用程序中显式实现。

The primary advantage of using this and not building a objective-C command line tool is that It offers an implicit run-loop with benefits including well defined callbacks when application finishes launch or during termination. This would need to be explicitly implemented in a command line app.

是否有任何缺点，例如功能中断？

Are there any disadvantages such as functionality break? Will the launch of the daemon be deferred?

推荐答案

对于守护进程，使用任何非守护进程安全框架。从技术说明TN2083：后台程序和代理 - 分层框架：

For a daemon, there are serious drawbacks to using any non-daemon-safe framework. From Technical Note TN2083: Daemons and Agents – Layered Frameworks:

分层框架

大多数Mac OS X功能是由大型系统框架实现的。
许多这些框架使用基于Mach的服务，他们使用引导服务查找
。如果
从引用错误引导
命名空间的程序中调用，这可能会导致各种问题。

Layered Frameworks

Most Mac OS X functionality is implemented by large system frameworks. Many of these frameworks use Mach-based services that they look up using the bootstrap service. This can cause all sorts of problems if you call them from a program which references the wrong bootstrap namespace.

Apple的这个问题的解决方案是分层：我们将框架
划分为多个层，并为每个层决定该层是否支持全局引导命名空间中的
操作。基本规则是，在CoreServices及以下版本（包括System，IOKit，System
Configuration，Foundation）中的
都应该在任何引导命名空间
中工作（这些是守护进程安全框架），而
上面的所有CoreServices（包括ApplicationServices，Carbon和AppKit）
需要一个GUI每会话引导命名空间。 ...

Apple's solution to this problem is layering: we divide our frameworks into layers, and decide, for each layer, whether that layer supports operations in the global bootstrap namespace. The basic rule is that everything in CoreServices and below (including System, IOKit, System Configuration, Foundation) should work in any bootstrap namespace (these are daemon-safe frameworks), whereas everything above CoreServices (including ApplicationServices, Carbon, and AppKit) requires a GUI per-session bootstrap namespace. …

总之，具体的建议是：

• 编写一个守护进程，只链接到守护进程安全框架（参见框架交互参考）。

编写GUI代理时，可以与任何框架链接。

When writing a GUI agent, you can link with any framework.

如果您正在编写一个守护程序，并且必须链接一个不是守护程序安全的框架，请考虑将您的代码拆分为一个守护程序
组件和代理组件。如果不可能，请注意
与将守护进程链接到不安全的
框架相关的潜在问题（如下一节所述）。

If you're writing a daemon and you must link with a framework that's not daemon-safe, consider splitting your code into a daemon component and an agent component. If that's not possible, be aware of the potential issues associated with linking a daemon to unsafe frameworks (as described in the next section).

危险生活





如果您的守护程序使用的框架不是守护程序安全的，您可以运行
进入各种各样的问题。

If your daemon uses frameworks that aren't daemon-safe, you can run into a variety of problems.

• 有些框架在加载时失败。也就是说，框架有一个初始化例程，假设它在每个会话的
  上下文中运行，如果不是这样，就会失败。

• Some frameworks fail at load time. That is, the framework has an initialization routine that assumes it's running in a per-session context and fails if it's not.

如果框架在加载时不会失败，那么当您从该框架调用各种例程时，您可能仍会遇到问题

If the framework doesn't fail at load time, you may still encounter problems as you call various routines from that framework.

• 例程可能会良好地失败。例如，例程可能会静默失败，或者打印一条消息到stderr，或者返回一个
  有意义的错误代码。

• A routine might fail benignly. For example, the routine might fail silently, or print a message to stderr, or perhaps return a meaningful error code.

例程可能失败敌意。例如，如果GUI框架由守护进程运行，则GUI框架调用abort是非常普遍的。

A routine might fail hostilely. For example, it's quite common for the GUI frameworks to call abort if they're run by a daemon!

例程可能工作，即使其框架不是正式守护程序安全。

A routine might work even though its framework is not officially daemon-safe.

例程可能会根据其输入参数而有所不同。例如，图像解压缩例程可能对于
的某些类型的图像工作，并且对其他图像失败。

A routine might behave differently depending on its input parameters. For example, an image decompression routine might work for some types of images and fail for others.

任何给定框架的行为，以及该框架中的例程，可以从发布版本改变。

The behavior of any given framework, and the routines within that framework, can change from release-to-release.

这样做的结果是，如果你的守护进程链接一个框架
，这不是守护进程安全的，你不能预测它将如何在
一般行为。它可能在您的计算机上工作，但在其他用户的
计算机上失败，或者在未来的系统版本上失败，或者因为不同的
输入数据失败。

The upshot of this is that, if your daemon links with a framework that's not daemon-safe, you can't predict how it will behave in general. It might work on your machine, but fail on some other user's machine, or fail on a future system release, or fail for different input data. You are living dangerously!

阅读整个技术说明以了解详情。

Read the whole technote for the full details.

这篇关于构建仅背景COCOA应用程序作为启动守护程序的缺点？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！