c - 文件描述符限制和默认堆栈大小

Question

在我工作的地方，我们构建并分发了一个库以及基于该库构建的几个复杂程序。所有代码都是用 C 编写的，并且可以在大多数“标准”系统上使用，例如 Windows、Linux、Aix、Solaris、Darwin。

我从 QA 部门开始，在最近运行测试时，我被多次提醒我需要记住将文件描述符限制和默认堆栈大小设置得更高，否则会发生不好的事情。 Solaris 和现在的 Darwin 尤其如此。

现在这对我来说很奇怪，因为我相信 0 需要环境摆弄才能使产品工作。所以我想知道是否有时这种要求是必要的邪恶，或者我们是否做错了什么。

编辑:

描述问题和一些背景的很棒的评论。但是我不相信我对这个问题的措辞不够好。目前，我们要求客户，因此也要求我们测试人员在运行我们的代码之前设置这些限制。我们不会以编程方式执行此操作。这不是他们可能会用完的情况，在正常负载下我们的程序会用完并出现段错误。所以改写这个问题，是要求客户更改这些 ulimit 值以在某些平台(即 Solaris、Aix)上运行我们的软件，还是我们作为一家公司让这些用户难以开始？

赏金:我增加了一笔奖金，希望能获得更多关于其他公司正在采取哪些措施来管理这些限制的信息。你能务实地设置这些吗？我们应该吗？我们的程序是否应该达到这些限制，或者这是否表明事情在幕后可能有点困惑？这正是我想知道的，作为一个完美主义者，一个看似肮脏的程序真的让我很烦。

Answer 1

如果您需要更改这些值以使您的 QA 测试运行，那么这不是什么大问题。但是，应该(恕我直言)避免要求客户执行此操作以使程序运行。如果不出意外，请创建一个包装器脚本来设置这些值并启动应用程序，以便用户仍然可以一键启动应用程序。然而，从程序中设置这些将是更可取的方法。至少，让程序在启动时检查限制，如果限制太低，尽早(干净地)出错。

如果软件开发人员告诉我，我必须弄乱我的堆栈和描述符限制才能让他们的程序运行，这会改变我对软件的看法。这会让我想知道“为什么他们需要超过我拥有的所有其他软件显然可以接受的系统限制？”。这可能是也可能不是一个有效的担忧，但被要求做一些(对许多人来说)看起来很老套的事情并不具有与您刚刚启动并运行的程序相同的专业优势。

当你说“这不是他们可能会用完的情况，在正常负载下我们的程序会用完并出现段错误”时，这个问题似乎更糟。超出这些限制的程序是一回事，但不能妥善处理因超出这些限制而导致的错误情况的程序则完全是另一回事。如果您达到文件句柄限制并尝试打开文件，您应该会收到一条错误消息，指出您打开的文件太多。在一个设计良好的程序中，这不应该导致程序崩溃。检测堆栈使用问题可能更加困难，但用完文件描述符绝不会导致崩溃。

您没有详细说明这是什么类型的程序，但我认为假设您的程序的用户必须有足够的权限来更改这些值是不安全的。在任何情况下，假设当您的程序在用户不知情的情况下运行时，没有其他任何东西可以更改这些值，这可能也是不安全的。

虽然总有异常(exception)，但我想说的是，通常超过这些限制的程序需要重新检查其代码。存在限制是有原因的，您系统上几乎所有其他软件都可以在这些限制内正常工作。您真的需要同时打开那么多文件，还是打开几个文件、处理它们、关闭它们然后再打开几个文件会更干净？您的库/程序是否试图在一个大包中做太多事情，还是将其分成更小、独立的部分一起工作更好？您是否因为使用可以以非递归方式重写的深度递归算法而超出堆栈限制？可能有许多方法可以改进相关的库和程序，以减轻更改系统资源限制的需要。