GNOME Bugzilla – Bug 766533
gl: win32: Setting pipeline to NULL from the callback of Form::onKeyPress deadlock
Last modified: 2016-09-29 13:29:43 UTC
I wrote a .NET application that renders video using glimagesink. In the C# code, I connect the form.KeyDown event and I set pipeline to NULL state from there. It deadlocks in DestroyWindow() from gst_gl_window_win32_close().
Created attachment 328014 [details] [review] gl: win32: Unparent internal window before destroying it For some reason DestroyWindow() deadlock if it's called from parent window's KeyPress event.
That patch fix the problem, but I'm not sure why, and I'm not sure it's the proper way for doing it. Any win32 expert around ?
There's probably some interaction with the window_proc and destroy window. IIRC, the window_proc is always called on the same thread for the majority of things which is the thread the window is created on.
Yes, it should call window_proc, doc says: "The function sends WM_DESTROY and WM_NCDESTROY messages to the window to deactivate it"[1]. DestroyWindow MUST be called from the thread who created the window (that's what we do) and window_proc will also be called from that same thread. I think window_proc is reentrant for that. But my knowledge of win32 is mostly 0... [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms632682%28v=vs.85%29.aspx
Review of attachment 328014 [details] [review]: Makes sense
Note that I don't have commit access, so if you're fine with the patch please merge it yourself. Thanks.
commit 098c5c16ad2b1c849c5893c0f81ef762144f69c6 Author: Xavier Claessens <xavier.claessens@collabora.com> Date: Mon May 16 17:11:53 2016 -0400 gl: win32: Unparent internal window before destroying it For some reason DestroyWindow() deadlock if it's called from parent window's KeyPress event. https://bugzilla.gnome.org/show_bug.cgi?id=766533
I'm guessing this was meant to be marked as resolved? If not, please re-open.
Xavier, is bug 752379 a duplicate now?
oh, I forgot I already reported that issue. I think the patch I made here is more a workaround than a real fix, d3dvideosink does it differently. Quickly checked the code there, and I see: PostMessage (hWnd, WM_DESTROY, 0, 0); DestroyWindow (hWnd); I should test if posting the message first change something.
*** Bug 752379 has been marked as a duplicate of this bug. ***