-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allow service workers to created nested dedicated workers #1529
Comments
Yeah, I think workers are currently linked to a root document, so that needs to be changed to "document or service worker global", or something common between the two. |
I think dedicated workers can be nested under shared workers right now? |
Would the idea be that the dedicated worker lives as long as the service worker is running? |
Correct. Its lifetime would be bound by the lifetime of its parent, just like when creating a dedicated worker in a window or iframe. |
FWIW, It would be useful for the new ManifestV3 browser extensions (currently implemented only in Chrome), which are built on service workers now so they've completely lost the ability to create workers in the background script. Looks like whatwg/html#411 |
I would love to see this become implemented into the service worker spec, I think it would be beneficial for highly computational fetch requests. |
I created a similar issue over in WHATWG: whatwg/html#8362 |
I think we've discussed this before, but I cannot find the issue. It would be nice to allow service workers to created nested dedicated workers via
new Worker()
. This would allow the service worker to perform CPU intensive operations, like custom decoding, without potentially blocking the thread being used to process further FetchEvents.chromeos/static-site-scaffold-modules#40 (comment) is an example of where this would be useful.
The text was updated successfully, but these errors were encountered: