Last 12 weeks · 0 commits
3 of 6 standards met
Hi, Thank you for this polyfill / proposal. I was wondering about the use of in web workers. As you probably know any code ran through is very unlikely to be optimised by V8 (see https://github.com/petkaantonov/bluebird/wiki/Optimization-killers). Would you know if this is also the case for in web workers? If so, wouldn't it make sense to avoid heavy long running code in the worker (that normally would become in the main thread after a short time)? Doesn't that defeat the whole point of using a worker in the first place (seeing as there is a reasonably significant cost to spawning and thread hopping)? Making a worker worth its weight in that case would be a significant challenge. Kind regards, Tim
Repository: developit/task-worklet. Description: Task Worklet: explainer, polyfill and demos. Stars: 278, Forks: 3. Primary language: JavaScript. Languages: JavaScript (100%). License: Apache-2.0. Topics: threading, threadpool, worker, worker-pool, worklet. Open PRs: 1, open issues: 3. Last activity: 4mo ago. Community health: 57%. Top contributors: developit, karol-majewski.
With threads in WASM coming up, there may be some merit to tying them with Task Queues
The API is request/response based, and as such doesn't have a natural fit for long running tasks. How do you see such tasks fitting into the model? For example, let's say I had a worklet which connects to a chat service (via http2 or websocket) and receives chat messages. Currently you could poll the worklet for the next message like so: I guess this is ok but it also doesn't seem ideal to me. I think it would make the worklet side more complex in a lot of cases (you might have to keep some global state to know which messages have been sent to which requester). It would be nice if tasks could also return a stream or something, so that you could use to await each message.