On Thu, Sep 10, 2009 at 10:46 AM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org">darin@chromium.org</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 class="gmail_quote">On Wed, Sep 9, 2009 at 3:37 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
<div>I'm really hesitant to expose explicit locking to the Web platform. Mutexes are incredibly hard to program with correctly, and we will surely end up with stuck locks, race conditions, livelocks, and so forth. For Workers I was happy that we managed to avoid any locking primitives by using a message-passing model, but explicit mutexes would ruin that.<br>
</div></div> <font color="#888888"><br></font></blockquote><div><br></div><div>Note: I probably made a mistake calling these locks since they do not work like normal mutexes.  You can only wait for one of these locks asynchronously.  There is no synchronous blocking, which avoids most of the problems you mention.<br>

</div></div></blockquote></div><br>I don't think it does. It makes deadlock less bad, because the application can still respond to events. But there will still be deadlocks in the sense that cyclic waits-for graphs will permanently stop the application from making progress. It won't help at all with livelocks or race conditions.<br>
<br>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>