RESOLVED FIXED 235186
Inject Launch Services database before NSApplication is initialized
https://bugs.webkit.org/show_bug.cgi?id=235186
Summary Inject Launch Services database before NSApplication is initialized
Per Arne Vollan
Reported 2022-01-13 09:00:29 PST
To avoid the main thread getting stuck, the Launch Services database should be injected before NSApplication is initialized, since the initialization now depends on the database.
Attachments
Patch (5.68 KB, patch)
2022-01-13 09:09 PST, Per Arne Vollan
no flags
Patch (5.70 KB, patch)
2022-01-13 09:29 PST, Per Arne Vollan
no flags
Patch (5.71 KB, patch)
2022-01-13 10:19 PST, Per Arne Vollan
no flags
Patch (5.74 KB, patch)
2022-01-13 14:18 PST, Per Arne Vollan
no flags
Patch (5.74 KB, patch)
2022-01-14 07:24 PST, Per Arne Vollan
no flags
Patch (1.23 KB, patch)
2022-01-17 17:21 PST, Per Arne Vollan
no flags
Patch (1.23 KB, patch)
2022-01-18 07:20 PST, Per Arne Vollan
no flags
Patch (8.64 KB, patch)
2022-01-19 13:14 PST, Per Arne Vollan
no flags
Patch (13.93 KB, patch)
2022-01-20 10:06 PST, Per Arne Vollan
cdumez: review+
Patch (13.80 KB, patch)
2022-01-20 15:59 PST, Per Arne Vollan
no flags
Patch (13.89 KB, patch)
2022-01-21 11:30 PST, Per Arne Vollan
no flags
Per Arne Vollan
Comment 1 2022-01-13 09:01:37 PST
Per Arne Vollan
Comment 2 2022-01-13 09:09:04 PST
Chris Dumez
Comment 3 2022-01-13 09:14:09 PST
Comment on attachment 449067 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=449067&action=review r=me > Source/WebKit/WebProcess/cocoa/LaunchServicesDatabaseManager.mm:87 > + auto startTime = WallTime::now(); Should probably be using MonotonicTime::now() > Source/WebKit/WebProcess/cocoa/LaunchServicesDatabaseManager.mm:89 > + auto elapsedTime = WallTime::now() - startTime; ditto. > Source/WebKit/WebProcess/cocoa/LaunchServicesDatabaseManager.mm:91 > + RELEASE_LOG(Loading, "Waiting for Launch Services database update took %f seconds", elapsedTime.value()); Can we use RELEASE_LOG_ERROR so that it stands out in the logs? Any delay during process initialization is very visible to the user and should be avoided.
Per Arne Vollan
Comment 4 2022-01-13 09:29:35 PST
Per Arne Vollan
Comment 5 2022-01-13 09:30:09 PST
(In reply to Chris Dumez from comment #3) > Comment on attachment 449067 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=449067&action=review > > r=me > > > Source/WebKit/WebProcess/cocoa/LaunchServicesDatabaseManager.mm:87 > > + auto startTime = WallTime::now(); > > Should probably be using MonotonicTime::now() > > > Source/WebKit/WebProcess/cocoa/LaunchServicesDatabaseManager.mm:89 > > + auto elapsedTime = WallTime::now() - startTime; > > ditto. > > > Source/WebKit/WebProcess/cocoa/LaunchServicesDatabaseManager.mm:91 > > + RELEASE_LOG(Loading, "Waiting for Launch Services database update took %f seconds", elapsedTime.value()); > > Can we use RELEASE_LOG_ERROR so that it stands out in the logs? Any delay > during process initialization is very visible to the user and should be > avoided. Done! Thanks for reviewing!
Simon Fraser (smfr)
Comment 6 2022-01-13 09:53:59 PST
Comment on attachment 449072 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=449072&action=review > Source/WebKit/WebProcess/cocoa/LaunchServicesDatabaseManager.mm:90 > + if (elapsedTime.value() > 0.5) if (elapsedTime > 0.5_s)
Chris Dumez
Comment 7 2022-01-13 09:54:32 PST
(In reply to Simon Fraser (smfr) from comment #6) > Comment on attachment 449072 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=449072&action=review > > > Source/WebKit/WebProcess/cocoa/LaunchServicesDatabaseManager.mm:90 > > + if (elapsedTime.value() > 0.5) > > if (elapsedTime > 0.5_s) Nicer indeed
Per Arne Vollan
Comment 8 2022-01-13 10:02:38 PST
(In reply to Simon Fraser (smfr) from comment #6) > Comment on attachment 449072 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=449072&action=review > > > Source/WebKit/WebProcess/cocoa/LaunchServicesDatabaseManager.mm:90 > > + if (elapsedTime.value() > 0.5) > > if (elapsedTime > 0.5_s) Will fix! Thanks for reviewing!
Per Arne Vollan
Comment 9 2022-01-13 10:19:56 PST
Per Arne Vollan
Comment 10 2022-01-13 14:18:54 PST
Per Arne Vollan
Comment 11 2022-01-14 07:24:01 PST
EWS
Comment 12 2022-01-14 09:11:55 PST
Committed r288019 (246045@main): <https://commits.webkit.org/246045@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 449171 [details].
Per Arne Vollan
Comment 14 2022-01-17 17:21:22 PST
Per Arne Vollan
Comment 15 2022-01-17 17:22:46 PST
Reopened, due to debug assert on EWS.
Per Arne Vollan
Comment 16 2022-01-18 07:20:34 PST
Simon Fraser (smfr)
Comment 17 2022-01-18 08:36:35 PST
Comment on attachment 449386 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=449386&action=review > Source/WebKit/WebProcess/cocoa/LaunchServicesDatabaseManager.mm:93 > + fprintf(stderr, "Waiting for Launch Services database update took %f seconds", elapsedTime.value()); WTFLogAlways.
Wenson Hsieh
Comment 18 2022-01-18 10:51:27 PST
Comment on attachment 449386 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=449386&action=review > Source/WebKit/WebProcess/cocoa/LaunchServicesDatabaseManager.mm:36 > +#import <wtf/NumberOfCores.h> Nit - do we need to import this header?
Per Arne Vollan
Comment 19 2022-01-18 11:27:25 PST
(In reply to Simon Fraser (smfr) from comment #17) > Comment on attachment 449386 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=449386&action=review > > > Source/WebKit/WebProcess/cocoa/LaunchServicesDatabaseManager.mm:93 > > + fprintf(stderr, "Waiting for Launch Services database update took %f seconds", elapsedTime.value()); > > WTFLogAlways. This patch is for debugging purposes, currently. I am speculating that writing to stderr will give us information about which test is sometimes hitting the debug assert. Thanks for reviewing!
Per Arne Vollan
Comment 20 2022-01-18 16:22:39 PST
(In reply to Wenson Hsieh from comment #18) > Comment on attachment 449386 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=449386&action=review > > > Source/WebKit/WebProcess/cocoa/LaunchServicesDatabaseManager.mm:36 > > +#import <wtf/NumberOfCores.h> > > Nit - do we need to import this header? Good catch! So far this patch is for debugging purposes, but will remove when a new patch is ready for review. Thanks for reviewing!
Per Arne Vollan
Comment 21 2022-01-19 13:14:20 PST
Chris Dumez
Comment 22 2022-01-19 13:30:51 PST
Comment on attachment 449510 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=449510&action=review This patch fails to update GPUProcessProxy.cpp accordingly. We can simplify things there now that sendNetworkProcessXPCEndpointToProcess() no longer needs a data store instance. > Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.h:281 > + static bool sendNetworkProcessXPCEndpointToProcess(AuxiliaryProcessProxy&); Now that it is static and doesn't use any information from the data store, I would suggest moving this to NetworkProcessProxy and make it non-static. Then WebProcessProxy could call `NetworkProcessProxy::ensureDefaultNetworkProcess().sendXPCEndpointToProcess(*this)`
Per Arne Vollan
Comment 23 2022-01-20 10:06:11 PST
Per Arne Vollan
Comment 24 2022-01-20 10:11:07 PST
(In reply to Chris Dumez from comment #22) > Comment on attachment 449510 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=449510&action=review > > This patch fails to update GPUProcessProxy.cpp accordingly. We can simplify > things there now that sendNetworkProcessXPCEndpointToProcess() no longer > needs a data store instance. > > > Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.h:281 > > + static bool sendNetworkProcessXPCEndpointToProcess(AuxiliaryProcessProxy&); > > Now that it is static and doesn't use any information from the data store, I > would suggest moving this to NetworkProcessProxy and make it non-static. > Then WebProcessProxy could call > `NetworkProcessProxy::ensureDefaultNetworkProcess(). > sendXPCEndpointToProcess(*this)` Fixed in latest patch. Thanks for reviewing!
Chris Dumez
Comment 25 2022-01-20 10:20:26 PST
Comment on attachment 449593 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=449593&action=review r=me > Source/WebKit/UIProcess/Network/NetworkProcessProxy.h:274 > + bool sendNetworkProcessXPCEndpointToProcess(AuxiliaryProcessProxy&); Personally, I feel we could drop "NetworkProcess" from the name now that it is located on the NetworkProcessProxy class. Your call. > Source/WebKit/UIProcess/Network/NetworkProcessProxyCocoa.mm:61 > + if (GPUProcessProxy::singletonIfCreated()) if (auto gpuProcess = GPUProcessProxy::singletonIfCreated()) > Source/WebKit/UIProcess/Network/NetworkProcessProxyCocoa.mm:62 > + m_networkProcess->sendNetworkProcessXPCEndpointToProcess(*GPUProcessProxy::singletonIfCreated()); *gpuProcess
Per Arne Vollan
Comment 26 2022-01-20 15:59:31 PST
Per Arne Vollan
Comment 27 2022-01-20 16:00:33 PST
(In reply to Chris Dumez from comment #25) > Comment on attachment 449593 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=449593&action=review > > r=me > > > Source/WebKit/UIProcess/Network/NetworkProcessProxy.h:274 > > + bool sendNetworkProcessXPCEndpointToProcess(AuxiliaryProcessProxy&); > > Personally, I feel we could drop "NetworkProcess" from the name now that it > is located on the NetworkProcessProxy class. Your call. > > > Source/WebKit/UIProcess/Network/NetworkProcessProxyCocoa.mm:61 > > + if (GPUProcessProxy::singletonIfCreated()) > > if (auto gpuProcess = GPUProcessProxy::singletonIfCreated()) > > > Source/WebKit/UIProcess/Network/NetworkProcessProxyCocoa.mm:62 > > + m_networkProcess->sendNetworkProcessXPCEndpointToProcess(*GPUProcessProxy::singletonIfCreated()); > > *gpuProcess Fixed! Thanks for reviewing!
Per Arne Vollan
Comment 28 2022-01-21 11:30:31 PST
EWS
Comment 29 2022-01-21 16:30:19 PST
Committed r288387 (246284@main): <https://commits.webkit.org/246284@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 449674 [details].
Per Arne Vollan
Comment 30 2022-01-27 13:02:05 PST
*** Bug 235719 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.