Closed Bug 579982 Opened 14 years ago Closed 14 years ago

Handle Pause and Resume with multiple processes


(Core Graveyard :: Widget: Android, defect)

Not set


(Not tracked)



(Reporter: blassey, Assigned: blassey)




(1 file)

In the single process world we handled this by blocking the message loop with a cond var. ( Even this approach needs more work to handle allowing things like downloads to happen in the background.
tracking-fennec: --- → 2.0a1+
Attached patch wipSplinter Review
Attachment #458588 - Flags: feedback?(mwu)
Assignee: nobody → blassey.bugs
Attachment #458588 - Flags: feedback?(azakai)
Comment on attachment 458588 [details] [diff] [review]

The parent process should *never* be paused because we have full control of it and we should be fixing things that are unnecessarily waking us.

The pausing should probably be a hint/observer topic so we can implement policy elsewhere.
See Also: → 581314
(In reply to comment #1)
> Created attachment 458588 [details] [diff] [review]
> wip

Looks good to me.

I think it would be very useful if this were scriptable, as at some point it would be great for addons to be able to control this. For example, an addon that lets you freeze particular tabs manually (once we have one process per tab), or if we add content throttling, then an addon to control that, etc.

(In reply to comment #2)
> The pausing should probably be a hint/observer topic so we can implement policy
> elsewhere.

I agree. We need to make a list of the relevant topics. For that, I would like to read the MeeGo docs for the application lifecycle, then compare to Android, and work based off of those two (working based on just one might lead to something not general enough). Currently I am waiting on the MeeGo docs.
do you really think that kill STOP is good way to suspend child process? how about web radio playing in background and some other features which probably want to be  alive in background?
(In reply to comment #3)
> We need to make a list of the relevant topics.

Let's summarize the various OS options here on this new wiki page:
tracking-fennec: 2.0a1+ → 2.0+
tracking-fennec: 2.0+ → 2.0b1+
handing this off to Alon since he's thinking about the big picture here
Assignee: blassey.bugs → azakai
Blocks: 583135
In there is a patch for
a nice scriptable interface for freezing processes (also throttling).

If feedback for that is ok, then we should change the patch in this bug to use that interface.
Depends on: 568054
Keywords: checkin-needed
Keywords: checkin-needed
The big picture approach has not been accepted (see bug 568054 for details). So this particular issue should be handled in an Android-specific way as best we can. Handing back to blassey for that.

If the above patch works well on Android, then let's just use that. Should probably move the stuff from dom/ipc into widget/src/android though.
Assignee: azakai → blassey.bugs
No longer depends on: 568054
That is a issue on meego too.
(In reply to comment #9)
> That is a issue on meego too.

I guess we need to determine if Meego has an application state that the OS tells us about, in which we can freeze Fennec. And whether it is safe then to freeze all of it or just content. But we should open another bug for Meego on this topic.
Attachment #458588 - Flags: feedback?(azakai) → feedback+
we are not going with this approach.  instead we are committed to addressing everything that's noisy after the child is suppose to be idle.

unblocking.  I will leave it to brad to close this bug if he feels so inclined.

Also see:  bug 359608, and bug 564118, and bug 584660
tracking-fennec: 2.0b1+ → ---
Attachment #458588 - Flags: feedback?(mwu)
Closed: 14 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.