[Webkit-unassigned] [Bug 233980] A dedicated worker is not frozen even when the page is in back/forward cache

[bugzilla-daemon at webkit.org]

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

--- Comment #10 from Mark Lam <mark.lam at apple.com> ---
(In reply to Yusuke Suzuki from comment #9)
> (In reply to Chris Dumez from comment #5)
> > (In reply to Alexey Proskuryakov from comment #4)
> > > Would it suspend threads holding mutexes, and freeze the main thread as a
> > > consequence?
> > 
> > You're right, I think that would be a risk indeed and very likely the reason
> > why our suspension logic currently works the way it does.
> > 
> > I guess timeout + kill is the way to go then.
> 
> Yes. One example is that malloc can have a global mutex for the slow path
> (e.g. stealing a page from the global heap instead of thread local heap). If
> we suspend a thread holding that mutex, most likely, soon, the other threads
> will be blocked once malloc happens.

We can use a mechanism similar to global GC's stop thread mechanism (doesn't exist yet) and stop the target thread at a GC consistent point.  Doing so ensure that the target thread won't be in the middle of any malloc operation.  That said, it doesn't guarantee yet that there won't be other locks that could be held.

If suspension is something we think we need, I can consider it in my GC work.  I think with a some work, it is achievable.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211209/a14fa300/attachment.htm>