And before you suggest using software transactional memory, keep in mind that side effects (XHRs and other network activity for example) are prevalent in normal JavaScript usage.
I don't mean to discourage you too much....especially if you were interested in digging really deeply into this stuff...but I can assure you that a lot of the more obvious, high level solutions to this stuff have been explored many times over. I think some of the more focused uses within specific implementations might be a better place to start. On Thu, Jan 7, 2010 at 1:36 PM, Charlie Reis <[email protected]> wrote: > The catch is that you don't know what locks you need to acquire in advance, > especially in the presence of things like eval. (And of course, you can't > roll back any JavaScript you've already run, so you would need to know the > locks in advance.) > > Charlie > > > On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel <[email protected]> wrote: > >> Hmm, I wonder if strict two-phase locking can be here to solve this? >> >> Fady >> >> >>> >>> That's correct. However, Fady is referring to an observation in my paper >>> that race conditions are actually possible in cross-window JavaScript calls >>> in Internet Explorer and Opera. Those browsers allow pages in different >>> windows to run in separate threads, even if they are from the same site and >>> can easily call into each other. From my tests, it appears that IE at least >>> tries to avoid race conditions by blocking one page until the other >>> finishes, but it allows the race if a deadlock occurs. >>> >>> You can test this fairly easily by calling a long-running function in >>> another page that is repeatedly calling the function itself. In Opera, both >>> pages' threads will be in the function at once. In IE, the first page will >>> be blocked until the second finishes, unless the second page tries to call >>> back into the first page at the end of its function. That would be a >>> deadlock, so instead they allow the data race. >>> >>> I don't think the spec allows for these races-- as people have mentioned, >>> JavaScript has a single-threaded, run-to-completion model. Chromium avoids >>> races by only putting pages that can't communicate on different >>> threads/processes. >>> >>> Charlie >>> >>> > > -- > Chromium Developers mailing list: [email protected] > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev >
-- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
