C Specification

To register a callback function with a memory object that is called when the memory object is destroyed, call the function

cl_int clSetMemObjectDestructorCallback(
    cl_mem memobj,
    void (CL_CALLBACK* pfn_notify)(cl_mem memobj, void* user_data),
    void* user_data);
clSetMemObjectDestructorCallback is missing before version 1.1.


  • memobj specifies the memory object to register the callback to.

  • pfn_notify is the callback function to register. This callback function may be called asynchronously by the OpenCL implementation. It is the application’s responsibility to ensure that the callback function is thread-safe. The parameters to this callback function are:

    • memobj is the memory object being deleted. When the callback function is called by the implementation, this memory object is not longer valid. memobj is only provided for reference purposes.

    • user_data is a pointer to user-supplied data.

  • user_data will be passed as the user_data argument when pfn_notify is called. user_data can be NULL.


Each call to clSetMemObjectDestructorCallback registers the specified callback function on a destructor callback stack associated with memobj. The registered callback functions are called in the reverse order in which they were registered. The registered callback functions are called and then the memory object’s resources are freed and the memory object is deleted. Therefore, the memory object destructor callback provides a mechanism for an application to safely re-use or free a host_ptr that was specified when memobj was created and used as the storage bits for the memory object.

clSetMemObjectDestructorCallback returns CL_SUCCESS if the function is executed successfully. Otherwise, it returns one of the following errors:

  • CL_INVALID_MEM_OBJECT if memobj is not a valid memory object.

  • CL_INVALID_VALUE if pfn_notify is NULL.

  • CL_OUT_OF_RESOURCES if there is a failure to allocate resources required by the OpenCL implementation on the device.

  • CL_OUT_OF_HOST_MEMORY if there is a failure to allocate resources required by the OpenCL implementation on the host.

When the user callback function is called by the implementation, the contents of the memory region pointed to by host_ptr (if the memory object is created with CL_MEM_USE_HOST_PTR) are undefined. The callback function is typically used by the application to either free or reuse the memory region pointed to by host_ptr.

The behavior of calling expensive system routines, OpenCL API calls to create contexts or command-queues, or blocking OpenCL operations from the following list below, in a callback is undefined.

  • clFinish,

  • clWaitForEvents,

  • blocking calls to clEnqueueReadBuffer, clEnqueueReadBufferRect, clEnqueueWriteBuffer, clEnqueueWriteBufferRect,

  • blocking calls to clEnqueueReadImage and clEnqueueWriteImage,

  • blocking calls to clEnqueueMapBuffer, clEnqueueMapImage,

  • blocking calls to clBuildProgram, clCompileProgram or clLinkProgram

If an application needs to wait for completion of a routine from the above list in a callback, please use the non-blocking form of the function, and assign a completion callback to it to do the remainder of your work. Note that when a callback (or other code) enqueues commands to a command-queue, the commands are not required to begin execution until the queue is flushed. In standard usage, blocking enqueue calls serve this role by implicitly flushing the queue. Since blocking calls are not permitted in callbacks, those callbacks that enqueue commands on a command-queue should either call clFlush on the queue before returning or arrange for clFlush to be called later on another thread.

The user callback function may not call OpenCL APIs with the memory object for which the callback function is invoked and for such cases the behavior of OpenCL APIs is considered to be undefined.

See Also

Document Notes

For more information, see the OpenCL Specification

This page is extracted from the OpenCL Specification. Fixes and changes should be made to the Specification, not directly.

Copyright 2014-2023 The Khronos Group Inc.

SPDX-License-Identifier: CC-BY-4.0