I didn't even think of the condition your code exposes. Partly because at the same time, if I wrote code that starts goroutines and doesn't have a section to close them, this deadlock condition created would also be exposing the fact that the worker pool is not being stopped correctly either.
That would mean your code, which breaks this code, also breaks the rule about never starting a goroutine without having a way to stop it. My code only fails when the caller is also failing. On Saturday, 4 May 2019 23:53:03 UTC+2, Jan Mercl wrote: > > On Sat, May 4, 2019 at 11:22 PM Louki Sumirniy > <louki.sumi...@gmail.com <javascript:>> wrote: > > > The first thing you will notice is that it is a LOT shorter. > > It fails a simple test: https://play.golang.org/p/v3OSWxTpTQY The > original is ok: https://play.golang.org/p/OhB8qZl2QLQ > > Another problem is starting a new goroutine per Waitgroup. Not only > that consumes more resources, but it is a way how to leak the > behind-the-scenes goroutine on any unexpected/incorrect usage pattern. > The original is immune to this problem. > > Also, please note that a select statement with one case only and no > default case can be replaced by that single case operation itself. > > And closing the channel on the receiving side is not something that > should usually be done. > -- 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.
