Open Bug 1597693 Opened 5 years ago Updated 2 years ago

Offer generic shutdown abstractions to (chrome) workers via ChromeWorker or PromiseWorker or its friends

Categories

(Toolkit :: Async Tooling, enhancement)

enhancement

Tracking

()

People

(Reporter: Gijs, Unassigned)

References

Details

Unfortunately there are some issues with workers and shutdown. It'd be nice if we could write some generic wrapper code that ensured that consumers could specify at what point worker wrapping code should stop processing requests to the worker (and return an error) due to shutdown having started, and/or ensuring we do not proceed past certain shutdown phases until the worker has finished handling pending transactions. I implemented something along these lines in bug 1594521 for the remote settings worker. It'd be nice to extend this to protect all chrome workers by default.

I didn't do this in that bug because of schedule pressure as well as these practical concerns:

  • I suspect the best place is inside ChromeWorker itself, which would impact lots of workers and could lead to hard-to-detect/fix race conditions / bugs
  • We use these workers in extant shutdown-sensitive code (esp. Session Restore)
  • It might be easier [for me] to write a patch for PromiseWorker, but that wouldn't have fixed the remote settings worker which isn't using PromiseWorker.

I think wherever we fix this, as Andrew suggested in bug 1594521 comment #12, we should ensure that consumers can indicate a desired shutdown phase, with the default being either profile-before-change or an earlier phase, at which point we'll ensure we terminate the worker after ensuring no pending promise-based requests are still going back/forth (with that last part blocking that phase of AsyncShutdown).

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.