-
Notifications
You must be signed in to change notification settings - Fork 390
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
Added access to Worker's terminate method when run through comlink-loaded #487
Conversation
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
@googlebot I fixed it. |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
A proxy doesn’t necessary sit on top of a I think your desire to get access to the worker is valid, but should be a bug on I’m closing this, but feel free to re-open if you disagree. |
It makes sense and I was thinking, too, it should be in comlink-loader. And rethinking about it and the code I put, it's also adding an unnecessary dependancy on Worker. I'm going to submit a pull request to comlink-loader then to solve the issue. |
@surma here is the pr GoogleChromeLabs/comlink-loader#27 |
When workers are loaded through
comlink-loader
there is no way to access the underlying Worker object through the proxy returned by comlink-loader and terminate it.This patch maps a terminate method on the proxy to the worker's terminate method.
proxy[Comlink.releaseProxy]()
is not enough in the case of Web Workers as the worker is not terminated only its endpoint if any is closed.