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
cases it can just happen peacefully in the background.
Except at shutdown, which is
http://code.google.com/p/chromium/issues/detail?id=19757.
On Wed, Sep 23, 2009 at 10:22 PM, Darin Fisher <da...@chromium.org> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
