[Webkit-unassigned] [Bug 95057] [chromium] Allow impl-thread deletion of only some resources

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=95057





--- Comment #34 from Eric Penner <epenner at chromium.org>  2012-09-05 13:17:26 PST ---
(In reply to comment #33)
> (In reply to comment #32)
> 
> > The only thing I'm worried about here is whether backing objects could be destroyed/created by other means while this task is in flight. If so these pointers don't uniquely identify backing objects any more.
> 
> So there does exist a bug here -- a reduceMemory() call can destroy a backing that has been handed to the main thread, but the main thread hasn't deleted yet.  I don't see a way around that without basically going back to the scheme of having a list of evicted textures in the PTM which is protected by a mutex (so, going back to the old scheme).

Can this actually happen though? reduceMemory() can only occur during a commit when the main thread is blocked, and it appears as though there can not be any other list of evicted backings in flight from when the task is posted through to when the commit is finished. So it seem to me we just need to process that list during the commit and we should be fine.

> 
> > (From update of attachment 162173 [details] [details])
> > As a last thought, I wonder if we could avoid having two backing sets, and instead copy a custom vector of structs like:
> > struct ImplBacking
> > { 
> >    Backing* backing,
> >    int priority;
> >    bool evicted;
> > };
> > Then we could just process that list before doing any other backing management in the commit (which all happens during updating textures). Thought for food.
> 
> From this it sounds like we're converging to a place where the m_backings vector is controlled entirely by the impl thread.  This makes sense to me -- that way we wouldn't have to have the extra BackingSet for the impl thread.  The change to do this would be fairly simple;
> - have prioritizeTextures() not touch the backings array because it's called on the main thread
> - add a prioritizeBackings() function to be called during commit, which pushes the texture priorities to their backings, and sorts the backings array
> - add a "int m_priority" to CCPrioritizedTexture::Backing
> 
> The mutex-protected list of evicted textures would still be needed, though.

I might be wrong, but could mutex be avoided like this?

During Commit:
   - Process eviction list and delete those backings
   - Manage lifetime of other backings via updating textures
   - Create a new eviction list for impl thread to use until next commit.
Main Thread:
   - Prioritize textures and backings but never manage backing life-times.
   - It should be impossible to manage backing life-times anyway since this
     requires the CCResourceProvider (commit only)
Impl Thread:
   - Mark it's own list of backings as being evicted.

Do we even need an event? Or maybe I'm missing something.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.