You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 14, 2022. It is now read-only.
Hi There,
This project looks really interesting. One thing I didn't see is - the ability to control or configure number of workers, mostly curious about controlling number of goroutines it will spin
Thanks
The text was updated successfully, but these errors were encountered:
@narup So the worker control is actually up to you and is manually controlled by how many workers you explicitly spin up with the help of a client such as go-workq: https://github.com/iamduo/go-workq#worker-commands. The workq server will happily accept as many worker connections as you give it.
The go-workq client works in a serial fashion and does not spin up any additional goroutines. It is up to the user to decide how they want to enable concurrency of a worker. There are a few different ways to go about this also within Go.
What you may be looking for/interested in is some type of higher level "Worker Library" that sits above the go-workq client that has already defined a concurrency strategy and allows you to wrap your user defined worker. This does not exist yet.
Let me know if you have any questions still or have a use case I can help address.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi There,
This project looks really interesting. One thing I didn't see is - the ability to control or configure number of workers, mostly curious about controlling number of goroutines it will spin
Thanks
The text was updated successfully, but these errors were encountered: