On Mon, May 4, 2009 at 12:15 AM, Darin Fisher <[email protected]> wrote: > 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?
One nice thing about X and the client/server model, is that there is a clear interface and description of what can happen. I don't think X ever "asks" an application for information, instead the application always tells X things, and X maintains the state. Therefore I can't imagine anything happening in X like this: App1 -> request -> X -> request App2 That is because X does not have a mechanism to ask things from the client, only to notify it about events. That said, we're using Xembed for plugins, and I don't know exactly what it involves. I would still be surprised to see this situation arise however. To quote some X tutorial: http://www.visi.com/~grante/Xtut/ As stated earlier, the X protocol defines what passes back and forth between the client and the server. The information that travels between client and server is broken up into ``packets'' at the X protocol level (which is different than Ethernet or TCP/IP packets or frames). There are four types of packets: - Request A request packet is sent by the client to the server to ask that the server perform some action or return some information. - Reply A reply packet is sent by the server to the client in response to a request from the server. Not all requests generate replies. - Event An event packet is sent by the server to the client to inform it of user input or some other happening about which it might want to do something (for example a window was re-sized or a previously obscured window was uncovered). - Error An error packet is sent by the server to the client to inform it that a request was not valid. Since requests are queued, the error might not be discovered until after several more requests have been queued by the client. > -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 -~----------~----~----~----~------~----~------~--~---
