I need your help. Currently i'm trying to create a worker pool that reads continuous jobs from a channel and then produces the result to the same channel it is reading from to then do work and produce the result to the same channel. you get the idea sorta like recursion. Is there any way to make this possible? I would really your appreciate advice on design patterns to implement this solution using go routines as a worker pool and channels to read in jobs and then from the same worker pool write the result of that job to the same channel to keep working. Thank you.
Asked
Active
Viewed 112 times
-1
-
1Why would you want to post a result / completed job on the same channel? If you do so, other workers may pick that up (what would they do with it? whatever would that be, the original worker that completed it could also do that without the resend / receive overhead). For recommendation, check out: [Is this an idiomatic worker thread pool in Go?](https://stackoverflow.com/questions/38170852/is-this-an-idiomatic-worker-thread-pool-in-go/38172204#38172204) – icza Nov 27 '18 at 17:01
1 Answers
0
There is no reason why something can't (from Go's perspective) write back to a channel after reading it:
func Foo(c chan int) {
x := <-c
// do something to x
c <- x
}
This is weird though... And honestly would not recommend it. Normally I have seen a system composed of several channels with data being passed down and not entering cycles. Think trees instead of graphs.

poy
- 10,063
- 9
- 49
- 74
-
Thank you for the response. I am solving a problem that should use recursion but that would cause memory issues. So I decided to try and implement a worker pool to continuously receive work from a channel, do the work, then pass that value back to the same channel it is receiving, and if one worker finds the value then I would like for them all to gracefully exit. I am having issues trying to figure out the best way to define this pattern without dealing with deadlock issues. would really appreciate some direction thank you in advanced – Jesse Lurie Nov 27 '18 at 17:16
-
-
I am currently experimenting with both. and have had better results with a buffered channel. – Jesse Lurie Nov 27 '18 at 17:30
-
Buffered channels will likely work better for you given the fact that the same go routine is reading a writing – poy Nov 27 '18 at 17:31
-
thank you! any suggestions on how to handle gracefully ending the go routines once the result is found ? – Jesse Lurie Nov 27 '18 at 18:32
-
I would use a shared context. Consume from the channel via a select where you read from the channel in one case and read from the Done() channel of the context on the other. Once you find the answer cancel the context. This will instruct all the other go-routines (who are also reading from the context) to bail. – poy Nov 27 '18 at 18:44
-
Thank you I will try to implement this. I Appreciate your time and responses – Jesse Lurie Nov 27 '18 at 19:37