Confirmed users
138
edits
Gecko:Shutdown issues: Difference between revisions
Clarification in the 2-phase shutdown proposal
m (fix another typo) |
(Clarification in the 2-phase shutdown proposal) |
||
| Line 33: | Line 33: | ||
Currently we go from stable state to shutdown, and the shutdown is this delicate mixture of destroying dynamic and static objects as well as we can. It would help a lot if we had a two-phase shutdown: | Currently we go from stable state to shutdown, and the shutdown is this delicate mixture of destroying dynamic and static objects as well as we can. It would help a lot if we had a two-phase shutdown: | ||
* Phase 1: All modules destroy all of their dynamic objects, but stay in a usable state. No more DOM objects or documents or gpu textures floating around at the end of this phase. If | * Phase 1: All modules destroy all of their dynamic objects, but stay in a usable state. No more DOM objects or documents or gpu textures floating around at the end of this phase. A cycle collection runs at the end of the phase to release the last dynamic objects. If there are still dynamic objects creating reference cycles after this, it should be considered to be a bug. | ||
* Phase 2: All modules shut down the way they do now, but without having to destroy all of | * Phase 2: All modules shut down the way they do now, but without having to destroy all of their dynamic objects synchronously (which is the cause of much of our trouble) since the latter are already gone. | ||
This is certainly a lot easier said than done, but managing shutdown the way we do now is arguably even harder. | This is certainly a lot easier said than done, but managing shutdown the way we do now is arguably even harder. | ||