我假设这个问题是依赖于操作系统或平台的。
它是在我使用端口音频库在Windows上编写C ++代码时产生的。
它在文档中声明不要在我的回调函数中写入太多代码，这些代码将传递给端口音频引擎，因为根据系统的不同，它可以从ISR调用，也可以从另一个论坛上读取，说明它可能导致堆栈溢出。
我不是要询问有关端口音频的具体内容，但我想知道如果在ISR中写入的代码多于在main函数中写入的话，为什么会出现堆栈空间问题。
我想从回调中调用一些不同的函数。如果实际从ISR调用此回调，则从ISR调用更多函数是一个问题吗？
当我调用每个函数时，这会给我额外的堆栈空间，因为每个函数都有自己的最大堆栈大小吗？这让我感到有些困惑。
我一直认为函数和ISR可以使用尽可能多的堆栈空间，直到完整分配的堆栈。这是否意味着主函数具有比其他函数更大的堆栈部分。
提前谢谢了。
如果实际从ISR调用此回调，则从ISR调用更多函数是一个问题吗？
它可能是。 ISR有很多种，在许多情况下使用，有些组合为ISR提供了相当有限的堆栈空间。堆栈空间（至少）由ISR自己的参数和局部变量以及它直接或间接调用的每个函数的函数调用，用于函数调用。该空间被重用于顺序函数调用，但是当一个函数调用另一个函数时它是累积的。
当我调用每个函数时，这会给我额外的堆栈空间，因为每个函数都有自己的最大堆栈大小吗？
不，一般不会。很可能使用自己的堆栈空间调用ISR，与其关联的任何程序的堆栈空间分开，但这是一种特殊情况。功能通常使用与其呼叫者相同的堆栈，但ISR没有传统意义上的呼叫者。
我一直认为函数和ISR可以使用尽可能多的堆栈空间，直到完整分配的堆栈。这是否意味着主函数的堆栈比其他函数更大[？]
ISR可以使用提供给它的堆栈空间。该空间通常与相关程序的主堆栈分开，这对于在ISR被触发时避免干扰主程序的状态是有用的，并且在ISR异步时是必要的。分开时，ISR的堆栈通常要小得多。
进程（主）堆栈的大小取决于系统，有时还取决于可执行文件;它在main和main直接或间接调用的所有函数之间共享。在单线程程序中，main确实可以访问比任何其他函数f更多的堆栈，但主要原因是main和（通常）从main到f的调用链中的每个函数都占用f无法使用的堆栈空间。
我想知道如果在ISR中写入的代码多于在main函数中写入的话，为什么会出现堆栈空间问题。
堆栈空间可能不是ISR的主要关注点。 ISR应尽可能简单快速，以尽量减少延迟，因此无论如何都不需要大堆栈。如果你必须进行任何非平凡的处理，你的ISR应该将一个任务排队，以便稍后在常规线程上运行以完成工作（有时称为上半部分和下半部分）。这可以通过条件变量，信号量或消息队列来实现（仅举几个IPC机制）。因此，如果ISR使用大量堆栈，则可能表明它正在尝试在时间关键的调度期间进行过多处理。
此外，许多系统（例如RTOS）要求您声明线程和ISR的堆栈大小。
我想从回调中调用一些不同的函数。如果实际从ISR调用此回调，则从ISR调用更多函数是一个问题吗？
只有在调用ISR中的其他功能时才应尽量减少，如上所述。您可以调用其他函数，但是在ISR返回到内核调度程序（以及未屏蔽的中断！）之后，您应该尽可能地推迟运行。
另外 - 小心竞争条件！谨慎使用互斥锁是保护共享状态所必需的。
当我调用每个函数时，这会给我额外的堆栈空间，因为每个函数都有自己的最大堆栈大小吗？这让我感到有些困惑。
不 - 函数没有自己的堆栈大小 - 线程可以。对于ISR，它取决于操作系统。调用每个函数会消耗更多的堆栈空间（基于调用嵌套级别）。
我一直认为函数和ISR可以使用尽可能多的堆栈空间，直到完整分配的堆栈。
是的，但堆栈是每个线程，而不是像堆一样的每个进程。使用大量的堆栈空间可能是设计问题的一个标志：在堆栈上分配大对象而不是堆，太多嵌套函数调用等。
这是否意味着主函数具有比其他函数更大的堆栈部分。
不，因为堆栈是每个线程。 main函数将位于应用程序调用堆栈的底部，但它可能会消耗少量或大量堆栈，这仅取决于其局部变量。
一些好的阅读：
老实说，我不相信“另一个论坛”。
文档没有说明使用过多的堆栈空间。它谈论了太多的代码，在ISR回调的背景下，它意味着在ISR中花费太多时间。
ISR（包括回调）在中断被阻止的情况下执行。现在中断不会累积;控制器只能说中断是否正在等待。如果ISR执行时间过长，则执行期间引发的中断将丢失。
堆栈空间也可能是一个问题，但首要的是，快速回调。
它是在我使用端口音频库在Windows上编写C ++代码时产生的。
请在ISR中尽可能少地进行操作，并将DPC排队以调用所有功能。即使DPC已经或应该受资源限制，因此请考虑工作线程为DPC提供服务的设计。无论你做什么，都不要考虑在ISR中获取任何互斥量。 EOR。