Yeah, it&#39;s a race condition - it seems to all depend on whether the worker resource gets loaded before the postMessage loop starts. Failure rate is around 30-50% on my machine.<div><br></div><div>It looks like events have priority in Cocoa, and I&#39;m guessing that performSelectorOnMainThread() creates events with a higher priority than those generated by URLConnection, which can lead to starvation. I&#39;m not certain what the right fix is, other than to maybe use a different method of dispatching events other than performSelectorOnMainThread that lets us set a lower priority?<br>

<div><br></div><div>-atw<br><br><div class="gmail_quote">On Mon, Mar 8, 2010 at 7:24 PM, Dmitry Titov <span dir="ltr">&lt;<a href="mailto:dimich@chromium.org" target="_blank">dimich@chromium.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At least user input is dispatched even if there are outstanding performSelectorOnMainThread calls: <a href="https://bugs.webkit.org/show_bug.cgi?id=23705" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=23705</a><div>

<br></div><div>
With the change in postTask, the cloneport test does not always hang - on my machine it&#39;s 50-50. There is some racing condition somewhere perhaps... <div><div></div><div><br><br><div class="gmail_quote">On Mon, Mar 8, 2010 at 5:29 PM, Drew Wilson <span dir="ltr">&lt;<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Following up with a related note - does anyone have any insight into how the Cocoa event loop dispatches events from different sources? In particular, I have a test (worker-cloneport.html) which posts a port back and forth between two endpoints (both on the main thread).<div>



<br></div><div>With the change to Document.postTask() I described earlier in this thread, this test results in there always being a pending event (posted via performSelectorOnMainThread) when we re-enter the cocoa runloop. It appears that the run loop *always* dispatches this event before dispatching events from NSURLConnection - the result is that any pending resource loads never complete.</div>



<div><br></div><div>Is there some kind of prioritization within the cocoa run loop so that certain types of events (like NSURLConnection events) if there are no pending events of other types?</div><div><br></div><div>-atw<div>


<div></div><div><br>
<br><div class="gmail_quote">On Mon, Mar 8, 2010 at 2:08 PM, Dmitry Titov <span dir="ltr">&lt;<a href="mailto:dimich@chromium.org" target="_blank">dimich@chromium.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



Many tasks are just fine to execute while modal UI is present. For example, XHR in a Worker probably should not be frozen by an alert on the parent page. That posts tasks to main thread for loader.<div>Also, it&#39;s unclear if a task can be simply delayed or in fact some other action should be performed at resume point - for example, timers re-calculate the next fire time. </div>




<div><br></div><div>Maybe there can be a generic mechanism for tasks to participate in suspend/resume... It&#39;d require a better definition of the events - for example, is there a difference between &quot;suspense on modal UI&quot; and &quot;suspense on going into BF cache&quot;? Probably there is.</div>




<div><br></div><div>Dmitrty<div><div></div><div><br><br><div class="gmail_quote">On Mon, Mar 8, 2010 at 1:45 PM, Drew Wilson <span dir="ltr">&lt;<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>&gt;</span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So the implication is that every single place that uses tasks has to have an associated activeDOMObject() or other hooks in ScriptExecutionContext so it can get suspend/resume calls and try to queue up the tasks for later? That seems a) hard (since not everything that uses tasks necessarily has an activeDOMObject), and b) fragile because we&#39;ll undoubtedly miss cases -- there&#39;s something like 70 calls to callOnMainThread()/postTask() in the WebCore code.<div>





<br></div><div>Is there no way to do something at a lower level? callOnMainThread() already keeps a queue of pending callbacks, so it seems like just not dispatching those callbacks might be better? It&#39;s tricky because you don&#39;t necessarily know which ScriptExecutionContext a task is destined for at that low level.<br>





<div><br></div><div>-atw<div><div></div><div><br><br><div class="gmail_quote">On Mon, Mar 8, 2010 at 1:24 PM, Dmitry Titov <span dir="ltr">&lt;<a href="mailto:dimich@chromium.org" target="_blank">dimich@chromium.org</a>&gt;</span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><div></div><div>On Mon, Mar 8, 2010 at 11:38 AM, Alexey Proskuryakov <span dir="ltr">&lt;<a href="mailto:ap@webkit.org" target="_blank">ap@webkit.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">






<div><br>
On 08.03.2010, at 11:21, Drew Wilson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, my question is: does it surprise anyone that tasks posted via callOnMainThread() are getting executed even though there&#39;s a modal dialog shown? And is there anything I should be doing in my task handler to make sure we aren&#39;t re-entering JS execution inappropriately in these cases? I&#39;m just concerned that the way we&#39;re posting tasks from worker threads to the main thread may cause reentrancy problems.<br>







</blockquote>
<br></div>
It is not correct to deliver messages from worker threads when an alert or a modal window is displayed. It may be ok for modal dialogs that are triggered asynchronously (such as credentials dialog).<br>
<br>
We have a manual test regression for a related issue, WebCore/manual-tests/js-timers-beneath-modal-dialog.html. You can compare how timers work, and how worker messages are delivered to find out how to fix the problem.<br>






</blockquote><div><br></div></div></div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">Timers are suspended by ScriptExecutionContext::suspendActiveDOMObjects/resumeActiveDOMObjects from PageGroupLoadDeferrer. So the context (Document) knows when it is suspended and when it gets resumed.</span></div>






<div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">It seems the task to process accumulated port messages can be postponed until resume.</span></div><div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- WBR, Alexey Proskuryakov<div><div><div></div><div><br>
<br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
</div></div></div></blockquote></div><br>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>