I ended up running in this issue recently, where I was cancelling execution on the device using a negative user event status, and being surprised my queue became unusable:
https://gitlab.freedesktop.org/mesa/mesa/-/work_items?sort=created_date&state=all&search=rusticl&first_page_size=100&show=eyJpaWQiOiIxNTU1NiIsImZ1bGxfcGF0aCI6Im1lc2EvbWVzYSIsImlkIjoxNTE3OTZ9
I think the documentation of clSetUserEventStatus should contain an adaptation of:
If the execution of a command is terminated, the command-queue associated with this terminated command, and the associated context (and all other command-queues in this context) may no longer be available. The behavior of OpenCL API calls that use this context (and command-queues associated with this context) are now considered to be implementation-defined. The user registered callback function specified when context is created can be used to report appropriate error information.
This would avoid people doing what I did without anticipating the consequences.
And we may want to think about an extension that would guarantee that the queue and context stay usable when termination is due to user events, or at least a way to obtain this behavior using user events (special status CL_CANCELLED?)
I ended up running in this issue recently, where I was cancelling execution on the device using a negative user event status, and being surprised my queue became unusable:
https://gitlab.freedesktop.org/mesa/mesa/-/work_items?sort=created_date&state=all&search=rusticl&first_page_size=100&show=eyJpaWQiOiIxNTU1NiIsImZ1bGxfcGF0aCI6Im1lc2EvbWVzYSIsImlkIjoxNTE3OTZ9
I think the documentation of clSetUserEventStatus should contain an adaptation of:
This would avoid people doing what I did without anticipating the consequences.
And we may want to think about an extension that would guarantee that the queue and context stay usable when termination is due to user events, or at least a way to obtain this behavior using user events (special status CL_CANCELLED?)