cocurrent bugs

[lwintermelon]

https://github.com/sigcn/pg/blob/3b97d1c8c0c0e0d05f973a36a479d82d94d178cb/disco/udp/udp.go#L56-L70 https://github.com/sigcn/pg/blob/3b97d1c8c0c0e0d05f973a36a479d82d94d178cb/disco/udp/udp.go#L177-L180

c.natEvents may be already closed, right?

For the dynamic added producer situation, I'm afraid WaitGroup is not enough.

[lwintermelon]

For the lifetime of channel, only after all producers are finished, the channnel is allowed to be closed, then all consumers will be released.

I personally think it's an anti-pattern to close a closeChan with a following close(dataChan) to notify the producers that it shouldn't send data to the channnel anymore. But the pattern is widely used in this project.

1. For single producer, it should be closed by producer when<-CloseCh is received.
2. For multiple producer 2.a if the ammount of producer is predicted, CloseCh+WaitGroup is enough. 2.b if producer may be dynamic created. 2.b.1 if you can tolerate missing message, you can make sure when CloseCh is trigger, all producers and consumers are finished, then let the GC to release dataCh 2.b.2 You can't accept messaage lost: solusion1: Mutex+ closed atomic.Bool+CloseCh+WaitGroup, solusion2, more go style, make a channel to start every producer. But I do think that the final solution will be that only close a channel when no body is using it, including the one who dynamic creates new producer, so both solution1 and solution2 are unnecessary. Any discussions?

Best wishes.