我假设我们希望进行错误处理，如this answer中所述，我们测试返回代码，如果不成功则抛出异常。
现在，假设cudaEventDestroy从之前的异步启动中返回错误，正如文档中所说的那样。
在这种情况下，该事件是否已成功销毁？更一般地说，如果从先前的异步启动中返回错误，我可以期望任何运行时函数成功完成其功能吗？
如果在我的代码中发生不方便实际处理错误的地方（例如析构函数），我该怎么办？
似乎，如果我不希望我的程序随机终止或丢失错误，我将不得不实施重复的错误记录系统，在那里我可以记录在可以＆＃39的地方发生的错误; t真正处理它们，并更改样板以进行运行时API调用，以检查返回状态和我的重复错误记录系统。这似乎相当尴尬和次优，我希望我能错过一些简单的东西。
答案 0 :(得分：2)
更一般地说，如果从先前的异步启动中返回错误，我可以期望任何运行时函数成功完成其功能吗？
一般来说，没有。由先前的异步启动引起的许多类型的错误都是使CUDA上下文无效的类型。一旦CUDA上下文无效，除了销毁之外，不能再进行任何类型的操作。鉴于此，您关于假设cudaEvent状态的问题没有实际意义。
如果在我的代码中发生不方便实际处理错误的地方（例如析构函数），我该怎么办？
许多类型的CUDA错误都是持久性的，尤其是那些反映了无效CUDA上下文的错误[1]。这些类型的错误无法清除，并会在任何后续的错误检查活动中重新出现。您可以通过全面的错误检查来获得适当级别的错误控制，除非在那些不方便的地方。如果您在析构函数活动期间对错误检查的关注特别是在应用程序拆除期间，则不清楚是否存在任何问题。
[1]：对于example：
＆＃34; cudaErrorIllegalAddress = 77设备在无效的内存地址上遇到加载或存储指令。不能使用上下文，因此必须销毁它（并且应该创建一个新的上下文）。此上下文中的所有现有设备内存分配均无效，如果程序要继续使用CUDA，则必须重新构建。＆＃34;
附加说明：
要获取异步启动示例返回的错误，应立即报告无法启用cuda上下文（例如无效启动配置）的错误，并且将通过正确的CUDA错误检查进行捕获在内核启动时，我不希望这些类型只能在以后显示，可能在析构函数操作期间。在内核执行开始后一段时间后发生的大多数错误属于使CUDA上下文无效的类型，并且是持久的，并且无法清除。