the process shortly:
I have a master spawning x goroutines with endless loops. They are running the whole time like a service, so let’s call them services. Now I need a way to communicate with them, like a „service bus“(?). I thought about creating a channel for each service but then I would have to make another routine for each service because it would block then.
So what do I need? A communication with each service. Doesn’t really matter if it’s only for a service stop or other things.
https://levelup.gitconnected.com/lets-write-a-simple-event-bus-in-go-79b9480d8997
Yeah I read that. That was the channel approach for each service with an additional routine
Pub/Sub architecture?
Yes that’s the architecture I found too, also the one which Mr. t linked
what exactly are your requirements?
My master has to talk with specific goroutines: if I want to talk with (let’s pretend they have ids) ID 5, I have to communicate with the certain service (goroutine), and do specific tasks. That’s why my first approach was a channel for each service where I can send data to the individual goroutine, maybe stored in a map with ID:Channel on my master thread. I just had no clue if that’s a good way to do. Now I will research a bit more about the mentioned architecture above, maybe that’s fitting - or maybe you have another idea. With the current idea I could say ”send message to channel services[5]“ (where 5 is the ID). Does that make sense? If not I will try to elaborate a bit different.
Is the communication bidirectional? Between workers and master
so what’s the problem with channels?
It’s more like a "shouldn’t there be a better way to solve that instead of having two routines for each service/worker"
I still don’t understand why you need two goroutines
Explained in my new answer
could you please point me to it?
Обсуждают сегодня