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 <fadysam...@gmail.com> 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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
