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 call back go functions to fill
receiving channel)*
*time.Sleep(3 * time.Seconds)*
*disconnect and log*
*killsig <- true*
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 am really curious about your example on select - is it a try... except
alternative? Can it be used in other scenarios?
func Fill(ch chan int, k int) {
select {
case ch <- k:
// sent
default:
// discard
}
}
On Fri, Apr 15, 2022 at 3:12 PM Brian Candler <b.cand...@pobox.com> wrote:
> 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 that server that
>> indicates everything is fine.
>>
>> So here is a gap between sending help and getting ready to receive the
>> "ok" response. It is a tiny gap but it is not possible that the other
>> server sends the "ok" message back through TCP connection just in this gap.
>> Yes my program handles the TCP message as always, in this case sends back
>> through the channel to the goroutine that has not prepared the select for
>> ticker channel and ok-receiving channel. Uh-oh, deadlock, crash! What is
>> your suggestion? buffered channel?
>>
>
> TCP sockets and Go channels are two completely different things.
>
> But in either case, if a receiver becomes ready before the sender, it's
> fine. The receiver just waits for data to arrive.
>
> And if the receiver is not ready first, it's also fine. The sender will
> send up to the buffer size (in the case of a buffered channel), and after
> that it will pause until the receiver is ready. (In the case of TCP you
> have quite a lot of buffering in network sockets; typically it could send a
> megabyte or more before it pauses).
>
> A pause is not a "deadlock". A pause is just waiting until it's OK to
> proceed.
>
> In this case you already admit that opportunity that the sending happens
>> when the receiver is not ready.
>>
>
> And there is no problem at all. It really doesn't matter if the sender
> becomes ready first, or the receiver becomes ready first. Here are two
> concrete examples, using an unbuffered channel:
>
> https://go.dev/play/p/r5eptx4dE7T
> https://go.dev/play/p/sTB5lio6Rhx
>
> Aside: in those examples I have used a sync.WaitGroup to ensure that the
> main program doesn't terminate until both the goroutines have completed.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/6ExktXrF5Xc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9a0a275e-54cf-40da-b0ac-8ce724fc3d49n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/9a0a275e-54cf-40da-b0ac-8ce724fc3d49n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CADEX6_X%3Dje43R%3DRQt8PWz64-r1VkDaoB8Z7F3b%3D7Y0byB___1g%40mail.gmail.com.
