You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On line 696 cmsplugin.cpp, there is a call to InitializeCriticalSection, but there is no corresponding call to DestroyCriticalSection anywhere.
Although the critical section is declared as static, DeleteCriticalSection is still needed, because when the CMS library is linked into a DLL, if that DLL gets repeatedly loaded and unloaded, a new instance of the critical section object will be leaked every time the DLL is unloaded.
I am also curious why on line 696, the _cmsInitMutexPrimitive function isn't used?
I think the idea was to call _cmsInitMutexPrimitive and _cmsDestroyMutexPrimitive, rather than directly call InitializeCriticalSection and DeleteCriticalSection.
The text was updated successfully, but these errors were encountered:
This is the main semaphore for context handling. It is there because in windows you cannot use a statically declared mutex. Strictly speaking this is a leak. It is there because there is no clean way to do onexit cleanup and because it is limited to windows, where a critical section is just a block of memory unless contention is detected, at which time an event object is created for synchronization. In principle, every process resource is cleaned up when the process exits. Kernel resources like event objects definitely follow this principle. So, unless you use the library in a very weird way you should not worry about that.
_cmsInitMutexPrimitive is a wrapper, whilst this portion of code is a windows-only hack. It calls directly the windows function to make clear what it is doing.
On line 696 cmsplugin.cpp, there is a call to InitializeCriticalSection, but there is no corresponding call to DestroyCriticalSection anywhere.
Although the critical section is declared as static, DeleteCriticalSection is still needed, because when the CMS library is linked into a DLL, if that DLL gets repeatedly loaded and unloaded, a new instance of the critical section object will be leaked every time the DLL is unloaded.
I am also curious why on line 696, the _cmsInitMutexPrimitive function isn't used?
I think the idea was to call _cmsInitMutexPrimitive and _cmsDestroyMutexPrimitive, rather than directly call InitializeCriticalSection and DeleteCriticalSection.
The text was updated successfully, but these errors were encountered: