+Adding back chromium-dev
-Munjal
On Wed, Sep 23, 2009 at 5:22 PM, Munjal Doshi 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 wrote:
>
>>
>> I think in our cu
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. In the
future, if we sync other types, i'm not sure whether they want to do
that or not. If that's true, then we don't really need to provide a
read write lock.
Howeve
I see. Yeah, we've had to deal with the "quit asap" issues in other cases
too. For example, the host resolver uses detached threads so that it can
simply leak a thread that is stuck on a getaddrinfo call. (FF does the same
thing.)
-Darin
On Wed, Sep 23, 2009 at 10:30 PM, Tim Steele wrote:
>
Not IO. The only contention it comes up against would be trying to get a
lock on data while another thread is applying changes that it already
received from a server, but that work is not intensive; it could be done by
the UI thread itself if it had to be, but it isn't since in the majority of
cas
Chrome's UI thread blocks on IO? Please tell me I misunderstand :-)
-Darin
On Wed, Sep 23, 2009 at 4:06 PM, Tim Steele wrote:
> If most of our uses on the UI thread are WriteTransactions today, then I
> agree using a Lock alone can't make things any jankier, because if you need
> to write you
If most of our uses on the UI thread are WriteTransactions today, then I
agree using a Lock alone can't make things any jankier, because if you need
to write you need the lock. I guess what I'm wondering is if we'll ever
discover we could improve UI responsiveness somehow by using a
ReadTransactio
[Moving to chromium-dev]
Good question.
One case where we do any large amount of work with a ReadTransaction is the
LoadAssociations step of model association. This happens just once at
startup, and I don't expect there's another thread trying to do read-only
operations on the syncable::Director
