+Adding back chromium-dev
-Munjal
On Wed, Sep 23, 2009 at 5:22 PM, Munjal Doshi <mun...@chromium.org> wrote:
> I am not sure. But it doesn't seem crazy to use sync data as a database
> directly for certain data types.
>
> -Munjal
>
>
> On Wed, Sep 23, 2009 at 5:04 PM, Jonathan Huang <ch...@google.com> wrote:
>
>>
>> I think in our current model, the outside entity that wants to sync
>> stuff with us needs to maintain a separate copy of their data. If
>> that's true, then we don't really need to provide a read write lock.
>> However, if we're used as a general database, we do. Is there a
>> compelling reason to use us as a database?
>>
>> On Wed, Sep 23, 2009 at 5:02 PM, Munjal Doshi <mun...@chromium.org>
>> wrote:
>> > One thing to think about is what would happen if we have multiple data
>> > types? If the lock is going to be scoped on the entire user directory
>> versus
>> > specific data type umbrella then we would have more contention. Of
>> course,
>> > this can happen in both simple lock or read/write lock world but
>> depending
>> > on how other data types are used (if many concurrent reads are needed
>> for
>> > example) read-write lock model might do better.
>> >
>> > In other words, even though read-write locks might not do much better
>> than
>> > simple locks today, they might do better in future.
>> >
>> > But I am not necessarily opposed to using simple locks right now..
>> >
>> > -Munjal
>> >
>> > On Wed, Sep 23, 2009 at 4:07 PM, brg <b...@chromium.org> wrote:
>> >>
>> >> Startup sync has little chance of collision as it is uncoordinated
>> >> between machines, but model association occurs here and can cause a
>> >> bit of a lag.
>> >>
>> >> Notifications incur a read immediately after being received from a
>> >> write. When a user has more than one client open, these will collide.
>> >> I think we can mitigate any problems with a small random wait which
>> >> occurs between receiving a notification and doing the sync.
>> >>
>> >> Polling should have little chance of collision.
>> >>
>> >> On Wed, Sep 23, 2009 at 3:34 PM, Jonathan Huang <ch...@google.com>
>> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > I talked to jim roskind about putting a read-write lock in chrome to
>> >> > replace our base transaction class and he was of the opinion that
>> >> > performance gains from rwlocks were often not very efficient. With
>> >> > that in mind, I think the way that our transactions work right now,
>> we
>> >> > have a multitude of writers and not all that many readers. I'm
>> >> > thinking of just replacing our transactions with a straight lock.
>> >> >
>> >> > Is there UI that blocks right now on acquiring a read transaction
>> >> > that's likely to bump into another read transaction, or other
>> >> > considerations I haven't thought through?
>> >> >
>> >> > --
>> >> > As seen on TV
>> >> >
>> >> > >
>> >> >
>> >>
>> >> >>
>> >
>> >
>>
>>
>>
>> --
>> As seen on TV
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
