[Webkit-unassigned] [Bug 106842] adding support for DiscardablePixelRef for caching lazily decoded images

[bugzilla-daemon at webkit.org]

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





--- Comment #115 from Min Qin <qinmin at chromium.org>  2013-01-28 22:11:42 PST ---
(In reply to comment #114)
> (In reply to comment #113)
> > (In reply to comment #98)
> > > (In reply to comment #96)
> > > > I submitted an unreviewed build fix: http://trac.webkit.org/changeset/141033
> > > > 
> > > > The use SkMutex is not necessary in this code so remove it would make Mac build happy. The reason for undefined reference is because of component build and SK_API.
> > > 
> > > We definitely need the SkMutex here. If we don't provide our own mutex, skia will fall back to use a static skmutex arrray. And the skmutex array has 30 mutex in it used in a ring fashion. 
> > > The problem is that 2 DiscardablePixelRef can later on use the same mutex and lead to deadlocks.
> > 
> > I don't think 2 DiscardablePixelRef locked on the same mutex will lead to deadlock, it's more like LazyDecodingPixelRef and DiscardablePixelRef locked the same mutex that can be a problem. I think we should fix this quickly and roll in a new Skia with SK_API for SkMutex.
> 
> Yes, you are right. Since cache entries are protected by a mutex in ImageDecodingStore, no 2 DiscardablePixelRef will call lockPixels/unlock pixels at the same. 
> However, as long as there are other Skpixelrefs in the same process, this could lead to deadlock. 
> Currently a process cannot use more than 32 skPixelRef if it is multithreaded, otherwise it will have to call setPrelocked or provide its own mutex.

well, actually we just need 2 SkPixelref to cause a deadlock. Just keep creating one and deleting it, until the 2 skpixelref starts to share the same mutex.

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