[webkit-gtk] Operation webkit_web_view_new() crashed when in multithreading
Carlos Garcia Campos
cgarcia at igalia.com
Thu Nov 20 00:16:06 PST 2014
El mié, 19-11-2014 a las 18:58 -0800, Niranjan Rao escribió:
> If it matters to you, we use 2.2.6 version. I don't know which webkit
> version and mode you are using. Things to do change a lot based on
> version and mode.
> My use case is much more complicated as we use java wrapper around
> webkit calls using Java Gnome library. We do use java threads though,
> so it's muti threading. To do multiple processing, we fire multiple
> processes because almost all our data needs authentication and we
> don't want to mix different users sessions. This is where I think next
> generation of webkit will be handy as network process seems to have
> some of the features I need, so potentially every tab in the window
> can have different session with same site and no mix up of data.
That's not correct. The network process doesn't ensure different
session. In multi web process mode, you have a single shared network
process, and one web process per web view, all of them sharing the same
web context (cookies, disk cache, etc.).
What you want is a different context for every web view, something that
hasn't been possible so far because we have always used a shared default
web context. We have recently landed a patch that allows to create new
web context. You can configure every web context differently to ensure
things loaded in different web views are independent to each other.
> Key to all your threading issues might be to lookup Gtk idle handler.
> Any operation that needs to be done on UI (that is on webkit DOM or
> view ) has to be channeled via idle handler. You queue up the function
> and wait in another thread until that function executes and signals
> you back. Doing lengthy operations in UI thread results in interesting
> crashes etc. I am not GTK expert, but kind folks on this list helped
> me a lot.
> As far as I know (based on what I have seen in code and process
> observations), webkit core is multi threaded with lot of asynchronous
> actions happening. As consumer of these, we just route request via
> idle handler.
Exactly, the API should be fully non blocking, so if you find anything
that blocks the main thread, please file a bug report. There well-known
cases though, like the plugin process scanning that we alleviated with
the plugins cache.
> More specific details if webkit-gtk list members don't object, we can
> discuss it here, otherwise you can PM me. In my opinion list is good
> place as it really relates to webkit and using it as a automated
> (heavy weight) tool rather than just simple browser to view documents,
> but I'll let others decide about interest in such features.
This is the perfect place to discuss about anything related to WebKitGTK
> On 11/19/2014 06:20 PM, 刘阳 wrote:
> > > Le mercredi 19 novembre 2014 à 10:09 -0800, Niranjan Rao a
> > écrit :
> > >> Agreed that webkit is heavy for these operations, but
> > after
> > >> experimenting with lot of sites we want to process and
> > tools that
> > >> were/are available, we concluded it was the best
> > technology. With XVFB
> > >> it works perfectly. My next goal is to experiment with
> > network process
> > >> model and see if we can reduce resource consumption
> > little more.
> > As you said, WebKit you use with xvfb works perfectly.
> > Does the WebKit you use is Multi-threading Or
> > Multi-processing ?
> > Or can you just show me a little methods or thought,
> > how you did when it needs high concurrency or just handling
> > some WebKitWebView at the same time?
> > Thanks !
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
Carlos Garcia Campos
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part
More information about the webkit-gtk