On Sat, Mar 28, 2009 at 11:29 AM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com">michaeln@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, Mar 24, 2009 at 2:11 AM, Ian Hickson <span dir="ltr"><ian@hixie.ch></span> wrote:<br><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On Fri, 20 Mar 2009, Jonas Sicking wrote:<br><div>
> I do think it would be great if workers had access to some type of<br>
> structured storage. However I agree that the fact that both the main<br>
> thread and workers have synchronous access to the same storage is not<br>
> acceptable since that means that we're violating the<br>
> shared-nothing-message-passing design that makes workers not have to<br>
> deal with locks and other traditional multithread hazards.<br>
<br>
</div>Agreed. The Database API seems well-suited for this, though.</blockquote><div><br></div></div></div><div>Again... its not just workers that are affected by this... speaking as someone</div><div>that works on a multi-threaded browser, this is troubling. If its possible to</div>

<div>spec features that allow script to poke at the world beyond the page</div><div>boundaries in a fashion that doesn't not require locking semantics beyond</div></div></blockquote><div><br>(I assume that "not" was unintended.)<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div></div><div>the scope of a single scriptable API call... that would be less troubling.</div>
</div></blockquote><br></div>SQL storage where the single API call is "run this complex transaction" might be acceptable.<br><br>But if the single API call is "access some shared state" and it's up to Web developers to deal with locking and synchronization --- that will never be acceptable. That burden must fall on browser developers, not Web developers.<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>