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 <[email protected]> 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 > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
