https://bugs.freedesktop.org/show_bug.cgi?id=76252
José Fonseca <jfons...@vmware.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bri...@vmware.com
--- Comment #4 from José Fonseca <jfons...@vmware.com> ---
Thanks.
The problem is DllMain calls and thread creation/destruction are serialized
(there are several mentions of this in MSDN and StackOverflow), hence the
deadlock.
I'm not sure the best way of solving this though. The difficulty here is that
WGL has no clear "Shutdown OpenGL" entry point, other than DllMain. I can't
see anywhere else we can shutdown.
The alternative to deadlock is leaking resources...
It might be worth to try a different alternative: instead of loading/unloading
llvmpipe's opengl32.dll and/or system opengl32.dll, I'd recommend you rename
llvmpipe's opengl32.dll it as "llvmpipe.dll" and keep it loaded all the time.
And simply switch between the system's entrypoints, vs llvmpipe's entry points.
This still has some difficulties, as GDI32.dll invokes opengl32.dll
directly....
I really don't see an easy way out...
One alternative would be to replace in lp_rast_destroy() the following code
/* Wait for threads to terminate before cleaning up per-thread data */
for (i = 0; i < rast->num_threads; i++) {
pipe_thread_wait(rast->threads[i]);
}
with a signal, i.e., instead of waiting for the threads to finish, simply wait
for the threads to signal they are ready to finish, which should happend
concurrently with DllMain.
Still, this business of shutdown on DllMain seems unsustainable in the long
term. Though I really don't a better alternative.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
