<div>In general this seems like a pretty interesting idea. It definitely would be nice to completely abstract away all concepts of concurrency from web developers, but some of our solutions thus far (message passing, async interfaces, etc) have not been terribly appreciated by developers either. The GlobalScript proposal is a good example: to us, shared workers were an adequate solution, but in practice the lack of shared state is very difficult for some developers to work around. Possibly even more difficult than dealing with some levels of concurrency.</div>
<div><br></div><div>I think it'd be interesting to introduce this as an experimental API and see what web developers do with it.</div><div><br></div><div><br></div><div>As for the idea of a sync API: What if some library/framework and the embedding page use these flags/locks? I know you can't actually deadlock with this API, but I worry some developers will just do |while(!acquireLock("flag")) {}| which could lead to deadlocks. Only allowing an async API would fix this, but developers have typically not liked async APIs.</div>
<div><br></div><div>Here's another idea that I think is actually kind of cool: What if we kept track of locking precedence (i.e. the graph of which locks have been taken while other locks were held) and threw an exception if any lock was ever taken in a way that violated the graph. In other words, we wouldn't make the developer tell us the locking precedence, and we wouldn't wait until you hit an actual deadlock. Instead we would look for the first call site that _could_ have deadlocked. A long time ago, I was working on a project that had some deadlock problems. We implemented exactly this and it worked pretty well.</div>
<div><br></div><div><br></div>On Thu, Sep 10, 2009 at 9:22 AM, Olli Pettay <span dir="ltr"><<a href="mailto:Olli.Pettay@helsinki.fi">Olli.Pettay@helsinki.fi</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 9/10/09 2:24 AM, Robert O'Callahan wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Thu, Sep 10, 2009 at 6:37 AM, Darin Fisher <<a href="mailto:darin@chromium.org" target="_blank">darin@chromium.org</a><br></div><div class="im">
<mailto:<a href="mailto:darin@chromium.org" target="_blank">darin@chromium.org</a>>> wrote:<br>
<br>
Yes, exactly. Sorry for not making this clear. I believe implicit<br>
locking for LocalStorage (and the implicit unlocking) is going to<br>
yield something very confusing and hard to implement well. The<br>
potential for dead locks when you fail to implicitly unlock properly<br>
scares me<br>
<br>
You mean when the browser implementation has a bug and fails to<br>
implicitly unlock?<br>
<br>
Giving Web authors the crappy race-prone and deadlock-prone locking<br>
programming model scares *me*. Yes, your acquireLock can't get you into<br>
a hard deadlock, strictly speaking, but you can still effectively<br>
deadlock your application by waiting for a lock to become available that<br>
never can. Also, how many authors will forget to test the result of<br>
acquireLock (because they're used to other locking APIs that block) and<br>
find that things are OK in their testing?<br>
</div></blockquote>
If you're concerned about that, make acquireLock to throw an exception.<br>
Authors sure will notice that things aren't quite right, if the flag<br>
isn't acquired.<br>
And if the acquireLock("flag", callback) approach is used, it is<br>
harder to make the mistake to not check whether the flag was really got.<br></blockquote><div><br></div><div>This seems like a good idea. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
As you said on IRC, perhaps there should be a way to acquire<br>
many flags at once and then call the callback.<br></blockquote><div><br></div><div>I like this idea as well.</div></div>