Last 12 weeks · 0 commits
1 of 6 standards met
Repository: developit/greenlet. Description: 🦎 Move an async function into its own thread. Stars: 4702, Forks: 98. Primary language: JavaScript. Languages: JavaScript (100%). Homepage: https://npm.im/greenlet Topics: thread, web-worker, webworker, worker, workerize. Latest release: 1.1.0 (6y ago). Open PRs: 2, open issues: 13. Last activity: 5y ago. Community health: 28%. Top contributors: developit, johnsonjo4531, spkellydev, MattSidor, sylvaindumont, styfle, joshuaquek, DCtheTall, bogas04, karol-majewski and others.
JavaScript
Great library, very useful stuff and absolutely love the size. :) I've only recently started learning about and took a look at the source code. So apologies in advance if I am wrong ;). 2 things caught my eyes: So if we do something like the following snippet (taken from the README), it seems that each new function instantiated via will reserve a new thread and a new URL reference. So, if there is a case wherein I don't need to use after a certain point in my code, those resources are still trapped. They may be very less in size to be of a practical concern, but I am not sure about it and would love if anyone can comment on that. However, if the output function comes with a method which releases those references, it could be useful. WDYT? Something like: Internally, it could call: Post , can itself become so it's not callable. Or can a more informative error: . Is there a downside to this approach if the contributors already considered any similar approach?
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: !spectacle b18024 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.