Ø The RW mutex is used by the implementation to guarantee that all handlers
are complete before we return from "Close", which is what I'm attempting to
test.
I’m not sure that the mutex is going to work like you want. There’s no
guarantee that the h.RLock() in the goroutine will execute in a timely fashion.
I think that you’d have to call it before the goroutine.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Evan Digby
Sent: 2016 September 13, Tue 14:59
To: golang-nuts
Subject: Re: [go-nuts] Having difficulty testing this "cleanly"
Hi John,
Consider the "main" function a test, and not a sane usage of the handler.
The multiple sync methods in "main" are trying to accomplish:
1) Ensure all tasks have started (allStarted waitgroup)
2) Wait until we're ready to call "Done" before we proceed with the task
(timeToFinish channel block)
These synchronizations wouldn't exist in actual usage. They're just test setup.
The RW mutex is used by the implementation to guarantee that all handlers are
complete before we return from "Close", which is what I'm attempting to test.
Thanks again!
On Tuesday, 13 September 2016 12:49:07 UTC-7, John Souvestre wrote:
Hi Evan.
I looked at the code you posted. I’m having a problem seeing exactly what you
are trying to do. Also, it appears to be using multiple synchronization
techniques: Mutex, WaitGroup, and 2 blocking channels.
Am I correct in guessing that you want to know how long it took to get all of
the tasks running? Then you want to wait till all of the tasks are complete?
If so, I’m thinking that using 2 WaitGroups would do the job – one to show when
all the tasks are running and one to show when all the tasks are done. No
mutex and no blocking channels.
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.
--
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.
