Updated the doc.
- Added "steps of conversion".
- Drawn a figure of the four steps of mojofication
I'm working on step1 now at this CL: https://crrev.com/2227593002
I'd appreciate any comments, thanks:)
So, tests which I have to fix are the following:
- ServiceWorkerJobTest
- ServiceWorkerHandleTest
- ServiceWorkerContextTest
- ServiceWorkerStallInStoppingTest
- ServiceWorkerContextRecoveryTest
For mojofication of SWDispatcher, I checked the IPCs received at SWDispatcher.
--
OnAssociateRegistration
OnDisassociateRegistration
OnRegistered
OnUpdated
OnUnregistered
OnDidGetRegistration
OnDidGetRegistrations
OnDidGetRegistrationForReady
OnRegistrationError
OnUpdateError
OnUnregistrationError
OnGetRegistrationError
OnGetRegistrationsError
OnServiceWorkerStateChanged
OnSetVersionAttributes
OnUpdateFound
OnSetControllerServiceWorker
OnPostMessage
--
Most of IPCs are responses to a message which is sent to SWDispatcherHost, and I think OnAssociateRegistration, OnDisassociateRegistration, OnSetControllerServiceWorker, OnPostMessage can be handled by ServiceWorkerProviderContext.
Thus, I'm planning to mojofy as the following five steps:
1. Mojofy all IPCs received by SWDispatcherHost and convert response messages to mojo callbacks.
2. Create an new mojo interface for SWProviderContext (mojom::SWProviderContext) and pass it at OnProviderCreated.
3. Mojofy OnAssociate/OnDeassociateRegistration.
4. Mojofy OnPostMessage/OnSetControllerServiceWorker with creating a connection between ServiceWorkerProviderContext and WebServiceWorkerProviderClient at WebServiceWorkerProviderImpl::setClient.
5. Remove ServiceWorkerDispatcher
I got a comment below from rockot@, and I found we cannot use AssociatedInterfacePtr bound with the Channel's associated group on the worker thread.
> You cannot use Channel-associated interfaces outside of the main thread or IO thread. Due to internal complexity which would result otherwise, we currently have no intention of supporting this use case.
And now I took a look at the IPCs sent to SWDH again to check which IPCs should be kept the ordering.
The following six IPCs are one-way (no reply) messages.
- ServiceWorkerHostMsg_ProviderCreated/Destroyed
- ServiceWorkerHostMsg_IncrementServiceWorkerRefCount/Decrement...
- ServiceWorkerHostMsg_IncrementRegistrationRefCount/Decrement...
- ServiceWorkerHostMsg_SetVersionId
ProviderCreated/Destroyed, SetVersionId are sent from the main thread, so it can be sent by using the AssociatedInterfacePtr.
The ref-counting IPCs could be problem. I'm now investigating what will happen if these objects are implemented by InterfacePtr.
Great work from shimazu, leon.han, xiaofeng.zhang, and others moving everything to Mojo!
Now that everything is Mojofied, should we mark this bug as fixed, and make a new bug for the follow-up work, especially if there is a rough plan we can sketch out for the remaining work?
I think we can call this fixed as there are no more legacy IPCs.
Remaining cleanup work can be separate bugs and onion soup is at issue 789857 or issue 612285.
Comment 1 by shimazu@chromium.org
, Jul 20 2016