W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

[whatwg] Structured clone algorithm on LocalStorage

From: Darin Fisher <darin@chromium.org>
Date: Thu, 24 Sep 2009 21:36:55 -0700
Message-ID: <bd8f24d20909242136sd9d5623q73b32c21763fb43c@mail.gmail.com>
On Thu, Sep 24, 2009 at 9:28 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Fri, Sep 25, 2009 at 5:52 AM, Darin Fisher <darin at chromium.org> wrote:
>> No, no... my point is that to the application developer, those "explicit"
>> points will appear quite implicit and mysterious.  This is why I called
>> out third-party JS libraries.  One day, a function that you are using
>> might transition to scripting a plugin, which might cause a nested
>> loop, which could then force the lock to be released.  As a programmer,
>> the unlocking is not explicit or predictable.
> The unlocking around plugin calls is a problem, but it seems to me that any
> given library function is much more likely start with a plugin-based
> implementation and eventually switch to a non-plugin-based implementation
> than the other way around.
Suppose a library decides to add sound effects one day.  They'd probably use

> Beyond plugins, I hope and expect that library functions don't suddenly add
> calls to alert(), showModalDialog() or synchronous XHR.
> Rob

Anyways, I will the first to admit that my argument is steeped in the
hypothetical, but when it comes to thread synchronization, it is important
to consider such unlikely cases.  I would greatly prefer a watertight
solution instead of just relying on probabilities.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090924/e785bca7/attachment.htm>
Received on Thursday, 24 September 2009 21:36:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC