On Wed, Sep 9, 2009 at 12:54 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div>Yet another possibility is to keep a per-domain mutex, also offer a transactional API, and accept that careless authors may indefinitely lock up the UI for all pages in their domain (up to the slow script execution limit) if they code poorly, but in exchange won't have unexpected race conditions with themselves.<br>
</div></blockquote><div> </div><div>I prefer this. If the app has a bug that causes one window to get stuck, most likely that's the window the user cares about anyway, so the other windows (temporarily) getting stuck is not a big deal. Also, if one window is hogging the database then an asynchronously dispatched transaction is going to be delayed indefinitely*, so some or all user operations in other windows will not be able to complete, even if the other windows appear to be responsive to events.<br>
</div></div><br>* Unless we adopt a model where scripts are required to detect aborts and restart.<br><br clear="all">Rob<br>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>