I know that webkitgtk is currently single web process, they are working to make it one process per web view, but not per frame afaik. In the blink announcement google mentioned they wanted to go one process per frame, which was not possible to do with webkit. I don't really know if single process is necessarily single thread here.<div>
<br></div><div>Can you explain where multi thread would be an issue in our code? Why I'm thinking perhaps simplistically is that we are already dealing with the window.sugar stuff being available asyncronously.<br><div>
<br>On Thursday, 19 December 2013, Code Raguet  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I've read the following, recently:<div>[...]<br>
<div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

In Opera, every window has its own JavaScript thread. This includes windows in iframes. The consequence is that event handlers initiated from different frames might execute at the same time. If these simultaneous scripts modify shared data (like properties in the top window), we have the possibility of race conditions.</blockquote>


<div>[...]</div><div>source: <a href="http://dev.opera.com/articles/view/timing-and-synchronization-in-javascript/" target="_blank">http://dev.opera.com/articles/view/timing-and-synchronization-in-javascript/</a></div><div>

<br></div><div>Because some pieces of sugar-web API ( for ex: env.js) relay on window.top props (and karma loads a context.html iframe and runs the specs within), I asked to myself if webkit frames may simultaneously run on different threads...</div>

<div><br></div><div>I always think in a single-threaded model when programming javascript (async, of course, but not multithreading). Therefore, It seems to me like an Opera specific.</div><div>After a little research, I wasn't able to find an concrete answer, so asked Roger to try out some tests.</div>

</div></div><div><br></div><div>We made a long running function with busy waiting loops that mutates a shared porp at window.top and then we ran it twice (one per frame) in Opera. As the doc says, we 've been able to make a (racy) non-deterministic state of the shared prop.<img src="cid:gtalk.341@goomoji.gmail" goomoji="gtalk.341" style="margin:0px 0.2ex;vertical-align:middle"></div>

<div><br></div><div>Same tests on Chrome showed single-thread behavior... <img src="cid:gtalk.328@goomoji.gmail" goomoji="gtalk.328" style="margin:0px 0.2ex;vertical-align:middle"></div><div><br></div><div>So the thesis would be running those on webkit... but we haven't yet</div>

<div>We had some unrelated issues and before keep digging I want ask you what do you think/know about...</div><div><br></div><div>Thanks,</div><div>Code</div></div>
</blockquote></div></div><br><br>-- <br>Daniel Narvaez<br><br>