On Thu, Sep 24, 2009 at 9:28 PM, Robert O'Callahan <[email protected]>wrote:
> On Fri, Sep 25, 2009 at 5:52 AM, Darin Fisher <[email protected]> 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
