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

[刘阳]

I am really appreciate you with patient, Niranjan : )
You help figure me out a way to solve the problem, I will just read some detail you show above and try it out later.

I am very greteful for everyone in the list, Thank you all here.

Regards,

Yang Liu
 
From: Niranjan Rao
Date: 2014-11-20 10:58
To: 刘阳
CC: webkit-gtk
Subject: Re: [webkit-gtk] Operation webkit_web_view_new() crashed when in multithreading
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.

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.

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.

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 !

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20141120/bcafbce2/attachment-0001.html>