Hello,
I hope this isn’t a boneheaded query. I’ve searched on this discussion board however haven’t seen fairly what I’m on the lookout for. This put up about attainable race circumstances appears a probable match.
I’ve been channels on golangdocs.com, sending customized information by way of channels. I’ve made one tiny change, including a Printf assertion to the known as operate. I’ll paste the entire code right here so it’s simple to see.
bundle major
import (
"fmt"
)
sort Individual struct {
Identify string
Age int
}
func SendPerson(ch chan Individual, p Individual) {
ch <- p
fmt.Printf("SendPerson %vn", p)
}
func major() {
p := Individual{"John", 23}
ch := make(chan Individual)
go SendPerson(ch, p)
identify := (<-ch).Identify
fmt.Println(identify)
}
If I run this code a number of occasions I normally see simply John. Generally I see:
SendPerson {John 23}
John
I don’t fairly perceive why. I assumed this was an error on my half as I ought to have put the Printf assertion within the known as operate earlier than the channel dealing with half as a result of I needed to see what I used to be receiving (that was the aim of including the Printf within the first place). However then I thought of it a bit extra. Why do I see this generally? I’d anticipate to see it all the time or by no means, however not generally seemingly at random. I’m not positive if that is linked to being buffered or unbuffered.
Can any individual level me in the appropriate path?
Many thanks,
John.
Hello @MrJohn
The SendMessage operate (and goroutine) ends earlier than it could print the message.
Attempt to print after which ship the message to the channel.
When the Predominant operate finalize, it kills all of the others goroutines.
It’s like a race situation.
Hello @GonzaSaya,
Thanks, I guessed it was a race situation. However I didn’t fairly perceive why.
Thanks once more.
John.
I’m actually don’t perceive your query totally. It print “John” becase you’re taking solely that half in
identify := (<-ch).Identify
fmt.Println(identify)
So if you need all of the construction within the channel, simply
perso := <-ch
fmt.Println(perso)
However as I say earlier than i’m positive if i perceive your query. Let me know…
Yamil
gorountine runtime is unsure.
attempt to this, it woundn’t till block that one msgs be ship to channle
for p:=vary ch{
fmt.Println(p.identify)
}
You’ll be able to change your method to ship message into channel to, since you assure that your message are logged, after all in case your program working in background, in case you solely can simply run and down, so you may block this wait the message into channel or use a sync.WaitGroup
bundle major
import (
"fmt"
)
sort Individual struct {
Identify string
Age int
Message chan string
}
func NewPerson(identify string, age int) *Individual {
return &Individual{
Identify: identify,
Age: age,
Message: make(chan string),
}
}
func (s *Individual) Ship(ch chan *Individual) {
s.Message <- "The message was despatched"
ch <- s
}
func (s *Individual) ReadMessage() {
go func(){
for m := vary s.Message {
fmt.Println(m)
}
}()
}
func major() {
p := NewPerson("John", 23)
p. ReadMessage()
ch := make(chan *Individual)
go p.Ship(ch)
fmt.Println((<-ch).Identify)
}
gorountine runtime is unsure.
Aha. I believe that solutions it.
Many thanks for the code. It does appear way more difficult than the unique instance.
I’ve been programming on and off with go for some time now, however haven’t actually accomplished something with channels. I used to be a bit stunned at just about my first take a look at them that I used to be getting a race situation of some kind, or no less than not anticipated behaviour.
I perceive, sure, if you run fmt.Print and so forth. there is no such thing as a assure that it is going to be executed as a result of there is no such thing as a order of execution of the goroutines, and in addition when your major goroutine finishes the others can even be completed, which might occur in case your print by no means seems
