" Strangely I found the start testing and disconnect log clustered and the
disconnect did actually happen. Then I switch back to the sequential case
that the receiving channel gots filled without receiving until
disconnection. It works now."
-- I found the error occurred again. It turned out
On Friday, 15 April 2022 at 08:31:17 UTC+1 yan.z...@gmail.com wrote:
> Thanks for your demonstration, Brian.
> Actually my code involving cgo is quite like your first case, like this
> code:
>
> *log("start testing")*
> *go func{*
> * for*
> * select*
> * case a: <=receiving*
> *
Thanks for your demonstration, Brian.
Actually my code involving cgo is quite like your first case, like this
code:
*log("start testing")*
*go func{*
* for*
* select*
* case a: <=receiving*
* case <- killsig*
*...*
*}()*
*subscribequotations*
*( meanwhile the cgo of the dll will
On Friday, 15 April 2022 at 06:47:09 UTC+1 yan.z...@gmail.com wrote:
> When one server finds something wrong, it sends out a request to another
> server for help.
> Then it makes a log and then a ticker to recheck the situation again and
> again and in the meantime, to receive a response from
Something bizarre happened in CGO. My new code started the anonymous
goroutine to receive first but it does not sleep below the goroutine and
jumps to end the function. So I returned to the sending before receiving
way, which guaranteed the program's safety.
There ain't always one way that fits
The fact that the sender may have to wait does not by itself make a
"deadlock".
It's a deadlock if the sender blocks and, due to poor programming, the
receiver is *never* ready to receive. That's a problem with your software,
not with Go's concept of channels.
Blocking on send until the
You are right, Brian.
The difference is not whether the channel is buffered or unbuffered - while
the receiver is present, none will encounter the deadlock.
package main
import (
"fmt"
"time"
)
//var c = make(chan int)
var c = make(chan int, 2)
func report(){
for{
