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 > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-gtk -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
