" 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 that
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 c
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 th
This code really blows my mind, Brian! I didn't know select can be flexible
as this:
package main
import (
"fmt"
)
var Ch = make(chan int, 1)
func Fill(ch chan int, k int) {
select {
case ch <- k:
// sent
default:
// discard
}
}
func main() {
fmt.Print
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 a
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 channe
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{
select
> I made up a work around that just dumps the new message if the buffer is
full:
You don't need to do that: use select { ... } to check if the channel is
ready to receive or not.
https://go.dev/play/p/Mb7VVCTvnfk
But in practice, this is almost never needed, because one goroutine is
doing the
