No, I don't think that llvmpipe or any other driver would have IPC data to
cleanup -- even with shared surfaces these things tend to be handled
transparently in kernel space.
But, from the documentation, it sounds like we should do no cleanup whatsoever,
i.e, we should skip both stw_cleanup_thread() and stw_cleanup().
I'll update your change to do this and push.
Jose
----- Original Message -----
When using LLVMPIPE on Windows 7 OS, i noticed that it is very simple to run
into a situation where the process hangs at application exit.
Precondition:
Activate multithreading using condition variables in
os_thread.h
by replacing
#if 0 && defined (_WIN32_WINNT) && (_WIN32_WINNT >= 0x0600)
by
#if 1 && defined (_WIN32_WINNT) && (_WIN32_WINNT >= 0x0600)
I remember this issue came up recently where it was explained that this is
currently not activated by default since Windows XP does not support those
condition variables.
However, the performance is much faster when using those condition variables,
so if XP support is not required one definitely wants to run in this mode.
When this mode is activated, i noticed that an application using LLVMPIPE based
OpenGL will typically hang at process exit. Attaching a debugger shows what the
root cause is:
At process exit
DLL_PROCESS_DETACH
is signaled at the method DllMain() in libgl_gdi.c, where then a final cleanup
is triggered by calling
stw_cleanup_thread();
stw_cleanup();
In stw_cleanup() code is triggered that tries to communicate a shutdown to the
spawned threads - however at that time those threads have already been
terminated by the OS and so the process hangs.
Here some info what Microsoft proposes in such a situation:
" When handling DLL_PROCESS_DETACH , a DLL should free resources such as heap
memory only if the DLL is being unloaded dynamically (the lpReserved parameter
is NULL ). If the process is terminating (the lpvReserved parameter is non-
NULL ), all threads in the process except the current thread either have exited
already or have been explicitly terminated by a call to the ExitProcess
function, which might leave some process resources such as heaps in an
inconsistent state. In this case, it is not safe for the DLL to clean up the
resources. Instead, the DLL should allow the operating system to reclaim the
memory. "
Following this proposal i modfied the DLL_PROCESS_DETACH handling in DllMain:
case DLL_PROCESS_DETACH:
stw_cleanup_thread();
if (NULL==lpReserved)
{
stw_cleanup();
}
break;
This change indeed solved this issue for me and LLVMPIPE runs fine.
The question that comes up for me is if LLVMPIPE has any inter process code
that would need cleanup in such a situation - otherwise one might think of
using this change to resolve this issue on Windows.
Any comments on this issue?
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
