Chrome's UI thread blocks on IO? Please tell me I misunderstand :-)
-Darin
On Wed, Sep 23, 2009 at 4:06 PM, Tim Steele <t...@chromium.org> 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 need the lock. I guess what I'm wondering is if we'll ever
> discover we could improve UI responsiveness somehow by using a
> ReadTransaction in places we haven't yet discovered. But I doubt it, since
> the UI has it's own cache (BookmarkModel) of the data that should be the
> only place it reads from.
> Except the ModelAssociator seems to use ReadTransaction.. I'm not that
> familiar with when that happens atm.
>
> On Wed, Sep 23, 2009 at 4:05 PM, Nick Carter <n...@chromium.org> wrote:
>
>> [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::Directory at the same time.
>>
>> Another case is TakeSnapshotForSaveChanges. But I don't see those two
>> interacting commonly.
>>
>> Most of the stuff that happens on the UI thread already needs a
>> WriteTransaction, and there shouldn't typically be contention for many of
>> the operations because of how we dispatch (via ModelChangingSyncerCommand)
>> those operations onto the UI thread.
>>
>> So really, I don't think we'd see an uptick in contention if we went with
>> a simpler lock.
>>
>> - nick
>>
>> 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
>>>
>>>
>>>
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
