Bug 213036 – [iOS] Skip rebuilding MobileGestalt cache if system is busy

• Component: WebKit Misc.
• Status: NEW

[Per Arne Vollan]

Rebuilding the MobileGestalt cache can block the main thread in the UI process for quite some time if the system is busy. We can check that the system is not busy before attempting to rebuild the cache.

[Per Arne Vollan]

rdar://problem/64001158

[Per Arne Vollan]

Created attachment 401562 [details]
Patch

[Darin Adler]

Comment on attachment 401562 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=401562&action=review

> Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm:470
> +            WTFLogAlways("MobileGestalt cache is not valid and IOKit is busy, skip rebuilding cache");

Gotta admit this is not easy to understand at all:

1) Why is it safe to ever skip this? Why in particular is it always safe to skip it if IOKit happens to be busy?
2) If it’s safe to skip this sometimes, then why is it sometimes critical to do it? How can we tell?
3) Why is skipping when IOKit is busy sufficient? Are there any other bad times to do this where IOKit isn’t busy, but there is some other reason that this could block the main thread for a long time? Is the fact that IOKit is not busy a guarantee that it’s a good time.

This policy must come out of a sophisticated understanding of the situation, but I don’t see anything here that makes it clear.

[Geoffrey Garen]

Comment on attachment 401562 [details]
Patch

I don't think this is the right next step. It's true that, if IOKit reports it is busy, then on some macOS builds MobileGestalt will hang for up to 5s before rebuilding the cache. But, if we choose not to rebuild the cache in this state, we'll reintroduce the bug where we can't render video (and possibly other bugs).

Rather than trading a new regression for an old regression, I think we need to come to a consensus on the right behavior here.

[Darin Adler]

If we understand what depends on the MobileGestalt cache, then one possible improvement is to start rebuilding the cache on a non-main thread and only block later, once we reach an operation that depends on the MobileGestalt cache.

I think that this is imperfect in at least these ways:

1) I don’t think we have a clear understanding of which operations depend on the MobileGestalt cache, and what all the "entry points" from WebKit to those operations all are. Not clear we have one or more good bottlenecks to do this.

2) I think it’s really easy to end up with an even worse problem if we choose the wrong synchronization mechanism and don’t end up getting the thread priorities right.

3) If the real problem here is that the cache is being invalidated in cases where it should not be, then we might still have hangs, so this will alter but not solve the problem.