Painting is not the only issue. On Windows there are several ways in which the thread responsible for a HWND can block waiting for the thread responsible for a child HWND to respond. Are you sure there are no X calls that block in a similar fashion? Are there no cases where you can query something about a child X window that would require asking the "client" associated with that X window to provide some data? -Darin
On Sun, May 3, 2009 at 1:36 PM, Evan Martin <[email protected]> wrote: > Two statements of fact first, and then a proposal afterwards. Please > correct my facts if I'm wrong. > > 1) On Windows, when you have a windowed plugin and paint the main > window, it synchronously (?) paints the child windows including > plugins. (This is the major point I'm unsure about; I don't > understand Windows very well. See > webkit/glue/plugins/test/plugin_create_instance_in_paint.cc [1] for a > test that indicates that this is the problem.) Because of this, we > can end up with a deadlock when the plugin WM_PAINT handler calls into > renderer javascript which calls back into the browser process (for > example, to query something like the screen size). We work around > this by handling those synchronous queries on the IO thread, not the > UI thread, in the browser process. > > 2) On Linux, queries about the screen (and clipboard handling) go via > X and GTK wraps X. GTK/X aren't implicitly threadsafe so we can't > directly handle the above queries on the IO thread; if we add locks we > recreate the deadlock problem. The alternative Adam hacked up is an > *additional* thread with its own connection to X, and then we must be > careful to not touch any GTK functions there. (This is especially > annoying because the point of using toolkits like GTK is that it > provides a nice interface to these functions.) > > > Ok, those were the facts as I understand them. Here's the thought: > maybe we don't have this synchronous painting problem on X. (It seems > strange to me it exists on Windows, maybe because I misunderstand the > problem.) I created a test app (code attached) that stuffs a child > process with a button in the host process, where clicking the button > makes the child process hang for five seconds. While the child is > hung, the button obviously doesn't repaint, but you can continue to > resize and observe the main window repainting. > > Conclusion, if the above is all correct: we don't need to go through > convolutions to avoid this deadlock problem. > - With little code change, we can proxy those renderer->browser calls > back to the UI thread on Linux only. r15028 [2] did just that. > - To be cleaner, we could just terminate those calls on the UI thread > (again, only on Linux) using the existing messaging infrastructure. > > (PS: I'm not sure if windowless plugins play into this at all. I > recall there's a potential for a synchronous paint in some > circumstances, but I believe that's synchronous between the renderer > and the plugin, right?) > > [1] > http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/plugins/test/plugin_create_instance_in_paint.cc > [2] http://src.chromium.org/viewvc/chrome?view=rev&revision=15028 > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
