- From: Darin Fisher <darin@chromium.org>
- Date: Thu, 24 Sep 2009 21:36:55 -0700
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 Flash. > 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. -Darin -------------- 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