[webkit-gtk] Operation webkit_web_view_new() crashed when in multithreading

[Carlos Garcia Campos]

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
+.

> Regards,
> 
> Niranjan
> 
> 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
> https://lists.webkit.org/mailman/listinfo/webkit-gtk

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20141120/5b1b1cee/attachment.sig>