Open Bug 989788 Opened 10 years ago Updated 2 years ago

Ability to define a timeout on a Task

Categories

(Toolkit :: General, defect)

defect

Tracking

()

People

(Reporter: gps, Unassigned)

References

Details

I would like the ability to define a timeout on a Task.

Essentially, you pass an optional timeout period when you create a Task. When the Task starts, a timer is created. If the Task is not resolved when the timer fires, the Task's promise is rejected and subsequent execution of the Task is aborted.

I could imagine people wanting 2 classes of timers/timeouts for tasks:

1) Total execution time of task. Beginning to end.
2) Idle time between generator yields.

I'm only asking for #1 here. But we may want to account for #2 as part of the API. (#2 also has performance implications since it means lots of timer resetting, which *might* be expensive?.)

There are plenty of use cases for this.

Many features may want to establish excessive timeouts on certain operations. If, say, Firefox Health Report doesn't initialize within 5 minutes, we reset it's state (perhaps by blowing away the database) and try again.

Tests are another use case. We have a huge problem with tests timing out. We have an add_task() API in the test harnesses for defining tests that run in terms of tasks. If the test runner created tasks with timeouts, it could more aggressively detect hung tests and abort them sooner.
I'm a little nervous of the side-effects that might happen here if people aren't thinking carefully. Leaks, corrupt files all come to mind. At the very least we should reject with a well defined value (Take.TIMEOUT?) so consumers can attempt to do something sensible. Maybe better though is to make the yield call that is currently pending throw an exception instead so the task itself can do cleanup appropriate to where the timeout occured.
Blocks: 1030270
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.