On Fri, Apr 3, 2009 at 9:00 AM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@google.com">jorlow@google.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 class="gmail_quote">The problem is escalating the lock.  If your script does a read and then a write, and you do this in 2 workers/windows/etc you can get a deadlock unless you have the ability to roll back one of the two scripts to before the read which took a shared lock.  If both scripts have an 'alert("hi!");' then you're totally screwed, though.</div>
</blockquote><div><br>Double oops! Yes.<br><br></div><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"><div><span style="font-family: 'Times New Roman'; font-size: 16px;"><div style="margin: 8px;">
On Wed, Apr 1, 2009 at 3:02 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org" target="_blank">robert@ocallahan.org</a>></span> wrote:<div class="gmail_quote"><div class="im"><br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
getItem stability is helpful for read-only scripts but no help for read-write scripts. For example, outside a transaction, two scripts doing putItem('x', getItem('x') + 1) can race and lose an increment.<div class="gmail_quote">

</div></blockquote><div><br></div></div><div>Totally agree that it doesn't quite work yet.</div><div><br></div><div>But what if setItem were to watch for unserializable behavior and throw a transactCallback when it happens?  This solves the silent data corruption problem, though reproducing the circumstances that'd cause this are obviously racy.  Of course, reproducing the deadlocks or very slow script execution behavior is also racy.</div>
</div></div></span></div></div></blockquote><div><br>You mean throw an exception when it happens? Yeah, that doesn't really help, you just replace one kind of random failure with another. A half-completed read-write script is very likely to have corrupted data.<br>
<br></div><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"><div><span style="font-family: 'Times New Roman'; font-size: 16px;"><div style="margin: 8px;">
<div class="gmail_quote"><div></div><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div>Addressing the larger context ... More than anything else, I'm channeling my experiences at IBM Research writing race detection tools for Java programs ( <a href="http://portal.acm.org/citation.cfm?id=781528" target="_blank">http://portal.acm.org/citation.cfm?id=781528</a> and others), and what I learned there about programmers with a range of skill levels grappling with shared memory (or in our case, shared storage) concurrency. I passionately, violently believe that Web programmers cannot and should not have to deal with it. It's simply a matter of implementing what programmers expect: that by default, a chunk of sequential code will do what it says without (occasional, random) interference from outside.</div>

</div></blockquote><div><br></div></div><div>I definitely see pro's and cons to providing a single threaded version of the world to all developers (both advanced and beginner), but this really isn't what we should be debating right now.</div>
</div></div></span></div></div></blockquote><div><br>Why not? I know of no better forum for debating the semantics of the Web platform, and it's clearly a matter of some urgency.<br><br></div><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"><div><span style="font-family: 'Times New Roman'; font-size: 16px;"><div style="margin: 8px;"><div class="gmail_quote"><div></div>
<div>What we should be debating is whether advanced, cross-event-loop APIs should be kept simple enough that any beginner web developer can use it (at the expense of performance and simplicity within the browser) or if we should be finding a compromise that can be kept fast, simple (causing less bugs!), and somewhat harder to program for.</div>

<div><br></div><div>If someone wants to cross the event loop (except in the document.cookie case, which is a pretty special one), they should have to deal with more complexity in some form.  Personally, I'd like to see a solution that does not involve locks of any sort (software transactional memory?).</div>
</div></div></span></div></div></blockquote><div><br>I agree it would make sense for new APIs to impose much greater constraints on consumers, such as requiring them to factor code into transactions, declare up-front the entire scope of resources that will be accessed, and enforce those restrictions, preferably syntactically --- Jonas' asynchronous multi-resource-acquisition callback, for example. That is entirely consistent with what I said above; I'm not saying all concurrency abstractions are intractable. But the "abstraction" which takes sequential code and adds races on shared storage everywhere certainly is.<br>
<br>Unfortunately we have to deal with cookies and localStorage, where the API is already set.<br><br></div><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"><div><span style="font-family: 'Times New Roman'; font-size: 16px;"><div style="margin: 8px;"><div class="gmail_quote"><div></div><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div>I realize that this creates major implementation difficulties for parallel browsers, which I believe will be all browsers. "Evil', "troubling" and "onerous" are perhaps understatements... But it will be far better in the long run to put those burdens on browser developers than to kick them upstairs to Web developers. If it turns out that there is a compelling performance boost that can *only* be achieved by relaxing serializability, then I could be convinced ... but we are very far from proving that.</div>

</div></blockquote><div><br></div></div><div>Like I said, a LOT of research has been done on concurrency.  Basically, if you're not really careful about how you construct your language and the abstractions you have for concurrency, you can really easily back yourself into a corner that you semantically can't get out of (no matter how good of a programmer you are).</div>

</div></div></span></div></div>
</blockquote></div><br>I know this, but I'm not sure exactly what point you're trying to make.<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>