I believe that this is because there is a race condition at

I believe that what is happening is that sometimes go routines that were scheduled later than other goroutines by these lines for a given channel get called first.

I see three ways to approach fixing this:

Option 1 is to simply bite the bullet and call out to each member's channel synchronously.
Option 2 is to start using a logical clock for events and passing those values through to the consumer
Option 3 also involves a logical clock, but it hides it from consumers by having an intermediate goroutine/channel pair running for each member that handles ensuring that the events are properly serialized

Can be useful if sender could wait until all members has received the broadcast message .

Thank you very much

https://github.com/grafov/bcast/blob/master/bcast.go#L114

go func(out chan interface{}, received *Message) { // non blocking
     out <- received.payload
}(member, &received)

This code can block, and keep the goroutine around, effectively being a memory leak.

Along with other gotchas (like reordering the messages), and other race condition, it makes this library unsuitable for any serious usage.

While I appreciate your effort and know this software comes with no warranty, please indicate that this library is buggy in README, delete it or accept the PRs from various sources addressing problems with it.

When invoking the Broadcasting method on a created Group with duration zero, the for loop in the function enters a tight loop. I believe this is because the test of

case <-time.After(timeout):

is always satisfied when timeout is zero. I tested out the addition of the following routine in my local build. When called the CPU usage is back to normal:

func (r *Group) ContinuousBroadcasting() {
    for {
        select {
        case received := <-r.in:
            switch received.payload.(type) {
            default: // receive a payload and broadcast it
                for _, member := range r.Members() {
                    if received.sender != member { // not return broadcast to sender

                        go func(out chan interface{}, received *Message) { // non blocking
                            out <- received.payload
                        }(member, &received)

                    }
                }
            }
        }
    }
}

Let me know if you want a pull request, or perhaps you'd like to refactor the select statement in Broadcasting yourself. BTW, love the package. Thanks!

So i have a piece of code:

for {                                                     
  msg := v.Recv()                                      
  c.Send(msg.(string))                               
}

What exactly happens when v(Member) closes? Will it infinitely block the reading? Because if it does, how this will affect my program, will GC recognize this as an infinitely blocking channel? Or what exactly happens?
So if something is smelly happens why not export some indicator that the Member is closed to stop this for loop?

Hey there, I was looking into your bcast library and noticed some tests fail on my machine with Go 1.5.1:

dq@empit:bcast$ go test -v
=== RUN   TestNewGroupAndJoin
--- PASS: TestNewGroupAndJoin (0.00s)
=== RUN   TestUnjoin
--- PASS: TestUnjoin (0.00s)
=== RUN   TestBroadcast
--- FAIL: TestBroadcast (0.10s)
    bcast_test.go:85: not all messages broadcasted
=== RUN   TestBroadcastFromMember
--- FAIL: TestBroadcastFromMember (0.10s)
    bcast_test.go:114: not all messages broadcasted
=== RUN   TestGroupBroadcast
--- FAIL: TestGroupBroadcast (0.15s)
    bcast_test.go:141: not all messages broadcasted
=== RUN   TestBroadcastOnLargeNumberOfMembers
--- FAIL: TestBroadcastOnLargeNumberOfMembers (1.05s)
    bcast_test.go:168: not all messages broadcasted (11267/16256)
FAIL
exit status 1
FAIL    github.com/grafov/bcast 1.415s
dq@empit:bcast$ go version
go version go1.5.1 linux/amd64

cheers/

I use your awesome library for years, but when switching to go1.9 dep seems to favour a released version instead of the master branch - somehow makes sense. :)

Can you release a new version, so that it can be picked up?

The README.md is no longer reflective of changes that seem to have been made in the past few days. I can see the pull request that was merged suggests a "massive refactor"... it would be quite useful to know what has actually changed and how to update my code.

Hi,

can you select between buffered and unbuffered broadcasting channel?

I would like to send a broadcast message to routine1 and routine2 using a broadcast channel...

go receiveData() {
broadcast <- rcv
}

go routine1() {
msg := <- broadcast
}

go routine2() {
msg := <- broadcast
}

Thanks,
Gerald