#Learning concurrency in go
14 messages · Page 1 of 1 (latest)
I've never heard the given quote before. I suspect what they mean is that rather than sharing memory between two goroutines, you can often achieve the same effect by communicating the changes in the memory they both care about through channels. I am somewhat guessing
if you can give something they're doing in the tutorial that you don't understand, send in what they're doing and maybe I can help explain what's happening
I'm not really familiar with the getName(). Someone else can probably answer this better than me.
so first u need to start the goroutines before sending thru the channel
second, if u have two goroutines that are reading from the same channel, if one of the goroutines takes something from the channel, the other one will no longer be able to take it as well. the channel removes something once it is read
I would say generally you shouldn't do logic with a goroutine based on its name. the logic should be done in the goroutine.
here is a working version of the example you gave
func main() {
messageChannel := make(chan string)
messageRaw := "hello"
go f(messageChannel)
go g(messageChannel)
messageChannel <- messageRaw
time.Sleep(time.Second * 8)
}
// IK WaitGroup is better than Sleep.
func f(message chan string) {
time.Sleep(time.Second * 2)
x := <-message
fmt.Println(x + " from main() in f()")
message <- x
}
func g(message chan string) {
time.Sleep(time.Second * 3)
fmt.Println(<-message + " from f() in g()")
}
here, f() will take from the channel, read it, then send it again, and g() will then catch it
the sleeps here are important. this is not guaranteed to work if f() and g() are sleeping the same amount of time
edited for maybe some clarity
Good luck
mfw I tell someone I can't answer the question and they still get mad