-
Notifications
You must be signed in to change notification settings - Fork 99
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
Support for terminating workers? #33
Comments
Hmm - the idea is that you should never be reexecuting greenlet() more than once per function. Creating threads in a loop is going to be bad for performance whether they get cleaned up or not. FWIW it should be possible to create self-destruction workers using close(): const foo = greenlet(async () => {
setTimeout(() => close());
return 'hello'
}); |
Where does Wouldn't it be good to expose a So WRT to the Readme example something like:
|
What I found is to only instantiate greenlet on the module level, never inside a class/component. This avoids re-instantiation and therefore memory leaks. This should probably be documented because it is very important. |
@NudelSieb yes, that's exactly right. I've added a section in the readme that clarifies this. Dynamic instantiation of workers for a task is rarely a good idea. |
First, thanks for developing and sharing this library! It looks great, and seems to make things much more ergonomic for many common use cases. I have an expensive computation I'm doing: This is my first time using Web Workers, but using vanilla workers, it looks like I can do this by calling Is there another way of doing this without |
At the moment it doesn't appear greenlet supports terminating threads. From my experimentation it appears that even if workers are not referenced they do not seem to be destroyed:
After about 20 threads the client will become unresponsive / crash.
Being able to do something like:
Would potentially help with the Web Worker lifecycle management.
The text was updated successfully, but these errors were encountered: