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<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">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 class="h5"><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>