Please see my in-line comments. Looping the b2g mailing list since some of the discussions might not be highly related to the point of view of Web APIs.
----- Original Message ----- > From: "Justin Lebar" <[email protected]> > To: "Jonas Sicking" <[email protected]> > Cc: "dev-webapi" <[email protected]>, "William Chen" > <[email protected]>, "Anne van Kesteren" > <[email protected]>, "Doug Turner" <[email protected]>, "Mounir > Lamouri" <[email protected]>, "EDUARDO > FULLEA CARRERA" <[email protected]>, [email protected] > Sent: Tuesday, May 7, 2013 3:57:48 AM > Subject: Re: Improving system messages to support webpages and more > > We probably also need to add "commit" semantics to system messages: > An > app would "commit" a system message after it's completely handled it, > and the main process could then stop re-delivering this system > message. In our current design, we do support an acknowledgement mechanism like the "commit()" you're talking about here. That is, the content process will internally send an acknowledgement back to the main process to clean up the pending message whenever the content process successfully receives a system message (please search "SystemMessageManager:Message:Return:OK" in SystemMessageManager.js). Let me try to elaborate more regarding our system message behaviours as below: When the main process attempts to fire system message, it will do the following 3 things: 1. Deliver the system message to the app (if it's alive). 2. Keep a copy of the system message in the pending queue (no matter the app is alive or not). 3. Try to launch the app (no matter it's alive or not). So we can discuss the following two scenarios before delivering the system message: A. The app (content process) is alive: The main process knows the app is running (at least at that moment) so it fires system message to the target content process (step #1). When the content process receives the system message, it will immediately fire an acknowledgement back to the main process. The main process will then clean up the pending message (queued by step #2) because it has been successfully delivered for sure. Note that the attempt of opening the app (step #3) doesn't really help because the app has already been running. However, we could still have an edge case that the app can probably be killed (due to OOM'ed) before receiving the system message or sending the acknowledgement back. Under this circumstance, the step #3 will eventually take effect and launch the app, then it will go to the following case B. B. The app (content process) is NOT alive: Obviously, the main process won't fire the system message to the content process because the main process understands the target isn't alive. Anyway, the main process will keep the system message in the pending queue (step #2). Later, the step #3 will then launch the app in the long run. When the launching app calls .mozSetMessageHandler(...), it will try to retrieve all the pending system messages from the central and clean them up at the same time [1]. If the app is launched manually by users instead of being launched by step #3, everything still goes the same except that the step #3 doesn't take effect. [1] A potential bug comes into my mind that we should also fire an acknowledgement back to clean up the system message, instead of cleaning it up during the retrieving process, because the retrieving process is an async one and the content process can be killed at any points. > Note that we cannot guarantee that after an app calls commit(), it > will never have that same system message delivered again, because the > app might get killed while running commit(). Our current acknowledgement mechanism doesn't take this into consideration. You're pointing out another potential bug here... We need to carefully go through the system message mechanism again based on the assumption that the content process can be 1) killed or 2) at any edge-case points. Gene _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
