Now I got it - thanks for the explanation.
Am Mi., 19. Dez. 2018 um 02:25 Uhr schrieb <mhhc...@gmail.com>:
> > feel unbuffered channels are safer to use especially in an acyclic
> directed graph of flowing values. Buffered channels seem to reduce blocking
> but I feel they come with the cost of such side effects like my initial
> problem of forgotten results in their channels.
>
>
> that happens with unbuffered channel too, if, for example, you mix it with
> a select on context cancellation.
> Maybe you are lucky and your data source provides a acknowledgment
> mechanism, maybe you are not and it s up to you to work around.
> This becomes a problem when the code can t be rationalized via an api that
> is able to wrap those behaviors.
>
> On Tuesday, December 18, 2018 at 8:50:20 PM UTC+1, Chris Burkert wrote:
>>
>> Robert,
>> it seems to me that you have a clear understanding about unbuffered vs.
>> buffered channels. I feel unbuffered channels are safer to use especially
>> in an acyclic directed graph of flowing values. Buffered channels seem to
>> reduce blocking but I feel they come with the cost of such side effects
>> like my initial problem of forgotten results in their channels. I would
>> love to hear/read/see more on the unbuffered vs. buffered tradeoff to get
>> rid of this gut feeling I am currently based on :-). Any good article you
>> can point me to?
>> Thanks
>>
>> Robert Engels <ren...@ix.netcom.com> schrieb am Di. 18. Dez. 2018 um
>> 17:03:
>>
>>> That code is incorrect as well when using buffered channels.
>>>
>>> On Dec 18, 2018, at 10:00 AM, Skip Tavakkolian <skip.tav...@gmail.com>
>>> wrote:
>>>
>>> why not just drop the select? i think the following is guaranteed
>>> because putting things on rc has to succeed before putting true into dc:
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> )
>>>
>>> func do(i int, rc chan<- int, dc chan<- bool) {
>>> rc <- i
>>> dc <- true
>>> }
>>>
>>> func main() {
>>> worker := 10
>>> rc := make(chan int, worker)
>>> done := 0
>>> dc := make(chan bool, worker)
>>> for i := 0; i < worker; i++ {
>>> go do(i, rc, dc)
>>> }
>>> for done < worker {
>>> r := <-rc
>>> fmt.Println(r)
>>> <-dc
>>> done++
>>> }
>>> }
>>>
>>>
>>> On Tue, Dec 18, 2018 at 5:35 AM Chris Burkert <burker...@gmail.com>
>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>> I have a couple of goroutines sending multiple results over a channel -
>>>> a simple fan-in. They signal the completion on a done channel. Main selects
>>>> on the results and done channel in parallel. As the select is random main
>>>> sometimes misses to select the last result. What would be the idiomatic way
>>>> to prevent this and completely drain the result channel?
>>>>
>>>> Here is a minmal example which sometimes prints one 0 but should always
>>>> print two of them:
>>>>
>>>> package main
>>>>
>>>> import (
>>>> "fmt"
>>>> )
>>>>
>>>> func do(rc chan<- int, dc chan<- bool) {
>>>> rc <- 0
>>>> dc <- true
>>>> }
>>>>
>>>> func main() {
>>>> worker := 2
>>>> rc := make(chan int, worker)
>>>> done := 0
>>>> dc := make(chan bool, worker)
>>>> for i := 0; i < worker; i++ {
>>>> go do(rc, dc)
>>>> }
>>>> for done < worker {
>>>> select {
>>>> case <-dc:
>>>> done++
>>>> case r := <-rc:
>>>> fmt.Println(r)
>>>> }
>>>> }
>>>> }
>>>>
>>>> many thanks
>>>> Chris
>>>>
>>>> --
>>>> 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...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
--
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.
For more options, visit https://groups.google.com/d/optout.
