The only thing I can thing of that involves a client->server->client->server->client world tour in X is selection handling, but that's asynchronous. Querying window properties only looks at server state (also true for the Mac's window server--there's no such thing as a synchronous call from the window server down into a client app).
--Amanda On Mon, May 4, 2009 at 4:08 AM, Dean McNamee <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
