I do mind being blocked, because if the test blocks (consider what's in "main" a test) then it is going to enforce the requirement that I want to see in the implementation. It won't protect me, and will make the test obsolete.
What I'm trying to test is that all handlers are complete after the call to "Close". I don't want the test code to be enforcing that. On Tuesday, 13 September 2016 12:54:21 UTC-7, John Souvestre wrote: > > Hi again. > > > > Ø There's no way to test that a WaitGroup is done without waiting for > it, and even if there was it would be racy because between the Close() and > WaitGroup wait call tasks could complete. > > > > If you don’t mind being blocked, then Wait is just what you want. Since > it’s occurring in the same function (main) that the Add is taking place > earlier, there is no race. > > > > John > > John Souvestre - New Orleans LA > > > > *From:* golan...@googlegroups.com <javascript:> [mailto: > golan...@googlegroups.com <javascript:>] *On Behalf Of *Evan Digby > *Sent:* 2016 September 13, Tue 14:19 > *To:* golang-nuts > *Subject:* Re: [go-nuts] Having difficulty testing this "cleanly" > > > > Hi John, > > > > Thanks for the reply. I've tried many incarnations that include > WaitGroups; however, none seem to achieve the desired result. > > > > If I add a WaitGroup with a defer done in the handler, and then wait after > the Close() then the test itself implements the requirement and won't > protect from future refactors. There's no way to test that a WaitGroup is > done without waiting for it, and even if there was it would be racy because > between the Close() and WaitGroup wait call tasks could complete. If I > wrapped the wait and the done in goroutines to see which one happened > first, also racy. > > > > If you have something else in mind can you elaborate on how it would help > in this case? > > > > Thanks again! > > > > Evan > > > On Tuesday, 13 September 2016 12:01:29 UTC-7, John Souvestre wrote: > > Have you considered using a sync.WaitGroup? > > > > John > > John Souvestre - New Orleans LA > > > > *From:* golan...@googlegroups.com [mailto:golan...@googlegroups.com] *On > Behalf Of *Evan Digby > *Sent:* 2016 September 13, Tue 13:56 > *To:* golang-nuts > *Subject:* [go-nuts] Having difficulty testing this "cleanly" > > > > Has anyone come across a good way, non-racy way to ensure that N tasks are > guaranteed to be completed after a function is called? Essentially I have a > “Close” function that must be guaranteed to block until all tasks are > finished. Achieving this was pretty simple: wrap each task in an RLock, and > then a Lock on close. > > > > Example: https://play.golang.org/p/7lhBPUhkUE > > > > Now I want to write a solid test to guarantee Close will meet that > requirement of all tasks must finish first for posterity. In that example, > try commenting out the RLock/RUnlock on lines 25/26. You'll see that it no > longer outputs many, if any, lines. I'm trying to prevent that from > happening in the future by some cowboy refactor! > > > > All of the ways I can come up with involve Sleeping or launching more > tasks than I _think_ can be finished in time--obviously not good! > > > > I feel like I must be missing some obvious way to test this and I'll end > up feeling silly once someone replies with the solution. I'm okay with that! > > -- > 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 <javascript:>. > 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.
