Comments (7)
I'm more in favor of using threads.js than the other 3 purely because of its (subjectively) straightforward APIs.
We can add a flag like useBackgroundWorkers
that will only accept onTick
functions that are enclosed in a threads.js expose
function and then through the Worker
API from threads.js execute them. Unfortunately, that means each function enclosed in an expose
will have to be on a separate file, but other then that there's no issue.
We can either install threads.js manually, or we can have it as a registered fastify plugin that we require whenever the useBackgroundWorkers
flag is true.
from fastify-cron.
Up to you if you want to support multiple multithreading libraries, but I like the idea of a common interface (and have separate packages that implement them, so we don't need peer dependencies).
Regarding data transfer, I'd wager to only do a one way main thread -> worker thread when we pass the Fastify instance, as we do as the argument of the cron callback in the single-threaded version. Not sure how the multithreading would impact references and things changing on the main thread (eg: changing the value of a property on the Fastify instance in a worker thread while there are things reading the value on request handlers).
from fastify-cron.
Apologies for the late reply.
Sounds good, will fork it and push a PR when ready :)
from fastify-cron.
I can work on this
from fastify-cron.
Great! How would you go about it?
from fastify-cron.
I'm fine with workers having to be declared in separate files, it's the same for web workers.
Is the flag necessary? Could we detect somehow that the onTick function is wrapped automatically? That would just be a nice-to-have though, I'm also happy with a flag.
Regarding dependencies, I'd rather leave threads.js as a peer dependency (ie: not bundle it). I'm not sure it needs to go through the Fastify plugin wrapping, though I guess it depends if/how consumers of this package already use threads.js.
from fastify-cron.
I guess a workaround we can do is have them give the path of the file that houses the function that must be executed on a worker_thread
, detect which lib they have installed (of the few we support) and then run it.
Some implementations might have differences in how they spawn a worker, pass data and shutdown a working thread so we might have to create some sort of interface that abstracts whatever lib is detected.
from fastify-cron.
Related Issues (5)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fastify-cron.