[chromium-dev] Re: [linux] GTK and multi-threading
Option (b) is better, as far as I can tell. On windows, those
messages have their own HWND anyway.
Adam
On Fri, Apr 10, 2009 at 1:15 PM, Ricardo Vargas wrote:
> I opened bug 7379 a while ago to implement option b on the windows side.
>
> On Fri, Apr 10, 2009 at 1:03 PM, Brett Wilson wrote:
>>
>> On Fri, Apr 10, 2009 at 12:42 PM, Evan Stade wrote:
>> > a) wrap the clipboard calls in gtk_threads_{enter,leave}(). This makes
>> > the calls thread safe, but it does so by locking a process-wide mutex,
>> > which will block our UI thread's main loop.
>>
>> I personally think this is OK. These calls "should" be on the UI
>> thread and we'd put them there if we could. So having them on another
>> thread blocking the UI thread seems equivalent. We just need to be
>> careful to limit the locking to just that.
>>
>> Brett
>>
>>
>
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] GTK and multi-threading
On Fri, Apr 10, 2009 at 1:03 PM, Brett Wilson wrote:
>
> On Fri, Apr 10, 2009 at 12:42 PM, Evan Stade wrote:
> > a) wrap the clipboard calls in gtk_threads_{enter,leave}(). This makes
> > the calls thread safe, but it does so by locking a process-wide mutex,
> > which will block our UI thread's main loop.
>
> I personally think this is OK. These calls "should" be on the UI
> thread and we'd put them there if we could. So having them on another
> thread blocking the UI thread seems equivalent. We just need to be
> careful to limit the locking to just that.
If in Linux plugin windows block the parent window (as they do on Windows),
then this will lead to a deadlock just as if the message was processed on
the UI thread.
>
> Brett
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] GTK and multi-threading
I opened bug 7379 a while ago to implement option b on the windows side.
On Fri, Apr 10, 2009 at 1:03 PM, Brett Wilson wrote:
>
> On Fri, Apr 10, 2009 at 12:42 PM, Evan Stade wrote:
> > a) wrap the clipboard calls in gtk_threads_{enter,leave}(). This makes
> > the calls thread safe, but it does so by locking a process-wide mutex,
> > which will block our UI thread's main loop.
>
> I personally think this is OK. These calls "should" be on the UI
> thread and we'd put them there if we could. So having them on another
> thread blocking the UI thread seems equivalent. We just need to be
> careful to limit the locking to just that.
>
> Brett
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] GTK and multi-threading
On Fri, Apr 10, 2009 at 12:42 PM, Evan Stade wrote:
> a) wrap the clipboard calls in gtk_threads_{enter,leave}(). This makes
> the calls thread safe, but it does so by locking a process-wide mutex,
> which will block our UI thread's main loop.
I personally think this is OK. These calls "should" be on the UI
thread and we'd put them there if we could. So having them on another
thread blocking the UI thread seems equivalent. We just need to be
careful to limit the locking to just that.
Brett
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] GTK and multi-threading
On Fri, Apr 10, 2009 at 12:42 PM, Evan Stade wrote:
>
> glib and x aren't thread-safe. To work around this our intention is to
> only call into them from the UI thread. Unfortunately we currently
> don't follow through on this.
>
> To query the clipboard the renderer sends a sync IPC call to the
> browser. The browser handles this call on the IO thread (in
> resource_message_filter.cc), where it calls into base::Clipboard. On
> linux this makes copious use of GTK+ functions (which in turn wrap
> calls to X). Oops! We'd like to be able to proxy off the calls to the
> UI thread, but I hear handling a sync IPC message on the UI thread is
> a nono. A couple options have been suggested, although neither is
> really all that appealing:
>
> a) wrap the clipboard calls in gtk_threads_{enter,leave}(). This makes
> the calls thread safe, but it does so by locking a process-wide mutex,
> which will block our UI thread's main loop.
Deadlock-wise, this is equivalent to just processing the message on the UI
thread. So it's a no-go..
>
>
> b) Create a second UI thread with its own X connection. Adam suggested
> this one so he's better able than I to explain the implications.
I'm not familiar with X so I can't comment on this. For background, the
problem we ran into on Windows is as follows:
-UI thread in browser process handles an input/paint/random Windows message,
which gets sent to a child window (plugin)
-browser UI thread effectively waits on the plugin UI thread
-plugin UI thread, as a result of the Windows message, ends up calling a JS
function on the page, or any other NPN_ function
-this results in a sync IPC message to the main renderer thread
If the main renderer thread then tries to do a sync IPC to the UI thread, a
cycle is reached and there's deadlock.
I don't know how child windows are implemented in Linux, and whether events
from parent->child will end up blocking the browser process' UI loop. If
this doesn't happen, then we can come up with some sort of abstraction that
dispatches the messages on different thread for different platforms. If it
has this same constraint, perhaps other things can be done on Linux (i.e.
will the sandbox prevent you from calling X functions?).
>
> Anyone with thoughts, advice, insight?
>
> p.s. So yes, webview copy-pasta is currently very dicey. You can
> always use the selection clipboard though, as long as you only care
> about text.
>
> -- Evan Stade
>
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
