DllMain(DLL_PROCESS_DETACH) calls FreeLibrary during process exit - causes CL_INVALID_OPERATION with oneDNN/OpenVINO

[ola2308]

Problem

PR #250 added khrIcdDeinitialize() in DllMain(DLL_PROCESS_DETACH),
but this is called AFTER C++ global destructors (oneDNN, OpenVINO)
have already tried to use OpenCL objects. Results in CL_INVALID_OPERATION (-59).

Root Cause

On Windows, DllMain/FreeLibrary is called at the end of process shutdown,
but C++ static destructors run BEFORE that. When oneDNN tries to cleanup
its OpenCL engine, the ICD platform table is already cleared.

Reproduction

• Run any oneDNN/OpenVINO app with multi-GPU (NVL with 2+ tile)
• Process exits with CL_INVALID_OPERATION errors from clGetPlatformIDs
• Logs: src/xpu/ocl/utils_shared.cpp:199

Proposed Fix

Check lpvReserved in DllMain:

• lpvReserved == NULL -> FreeLibrary() call (WinML unload) → cleanup safe ✅
• lpvReserved != NULL -> process exit → skip cleanup ✅

if (reserved == NULL) {
khrIcdDeinitialize();
}

Note
This ONLY affects Windows. Linux/Unix don't have this issue
(dlclose happens after C++ destructors).

[bashbaug]

The proposed fix sounds reasonable to me.

For reference, see https://learn.microsoft.com/en-us/windows/win32/dlls/dllmain:

If fdwReason is DLL_PROCESS_DETACH, lpvReserved is NULL if FreeLibrary has been called or the DLL load failed and non-NULL if the process is terminating.

[bashbaug]

I think there are actually two issues described here:

The first is the call to FreeLibrary during process exit. This issue should be fixed by #275. It's a slightly refined variant of the proposed fix described above, but importantly it will omit the unsafe calls to FreeLibrary during process exit.

The second is the CL_INVALID_OPERATION error code. This is caused by the installation of the "deinit" dispatch table during de-initialization, and ensures that OpenCL calls made after deinitialization return an error message vs. calling into de-initialized layers or ICDs:

OpenCL-ICD-Loader/loader/icd.c

Lines 596 to 601 in b7bd280

	// free layers first in reverse order of their creation (front to back)
	// they may still need to use vendors while terminating
	KHR_ICD_TRACE("finalizing and unloading layers\n");
	struct KHRLayer *head = khrFirstLayer;
	deinitLayer.dispatch = khrDeinitDispatch;
	khrFirstLayer = &deinitLayer;

I think this the right behavior and the only safe thing to do, but I suppose other behaviors are possible, too.

FWIW, the OpenCL spec says (in an appendix):

The behavior of OpenCL API functions called from global constructors or destructors is therefore implementation-defined.