-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
exiting program without waiting for the completion of all commands #1238
Comments
This may be the best we can do, but I'd like to at least explore some alternatives, since OpenCL currently does not provide a mechanism to ensure that all commands executing on a device have completed similar to vkDeviceWaitIdle in Vulkan. Let's assume that all OpenCL objects have been properly released, and in particular all OpenCL command queues and the OpenCL context used to create the command queues have been released. Could we find a way to say that this case is well-defined? For reference, the spec currently says that clReleaseCommandQueue performance an implicit command-queue flush, but not an implicit command-queue finish. (Aside: it's ambiguous whether this happens for any command-queue release or just the last one that cause the reference count to go to zero.) Perhaps we say something like: any commands that are in-flight (meaning: their execution status is not I'd really like to avoid a case like the one below, where the following code anywhere in a program could lead to undefined behavior given the proposal above, because there's no way to confirm the commands are complete after the command-queue is released.
|
"any commands that are in-flight (meaning: their execution status is not CL_COMPLETE) may be abnormally terminated when the context is destroyed" - sounds good to me. |
The spec is unclear about what happens when function
main
returns while commands are still in flight, even if their queue has been released.The problem is that the finalization flow in C/C++ after
main
has returned is not well-defined and is platform-dependent. That might lead to things like crashes, deadlocks, or resource leaks.I propose adding a note in the spec that applications must ensure all enqueued commands have been completed before exiting
main
, otherwise the behavior is undefined.The text was updated successfully, but these errors were encountered: