That is ok, though, because the goroutine is exiting anyway. But I take
your point, it's still a race condition -- two atomic operations in a row
aren't helping. It's the same situation as testing (but not acquiring) a
mutex before entering a function.
On Friday, August 18, 2017 at 9:59:51 PM U
Thanks to both for replying. Both pieces of advice cover the use case of
waiting for all goroutines to complete before exiting. I have the opposite
problem. I want to end all goroutines if I exit. Is there anything in the
sync package for that?
On Friday, August 18, 2017 at 2:40:39 PM UTC-4, Ta
Hi,
https://play.golang.org/p/lR6_mxSjtb
I have two long running things to do, I'd like to do them in parallel, then
sync up at the end. I've written it as a function which gets one thing
done, and which backgrounds the second thing with a goroutine. Thing one
has a lot of reasons to exit earl
at are out of range, handle paths that
are longer than the struct is deep, etc. But what i've shared runs against
the sample json.
On Tuesday, November 1, 2016 at 1:04:21 PM UTC-4, wwa...@gmail.com wrote:
https://play.golang.org/p/LhOTUuTVqA
On Tuesday, November 1, 2016 at 12:50:09 PM UTC
e, handle paths that
are longer than the struct is deep, etc. But what i've shared runs against
the sample json.
On Tuesday, November 1, 2016 at 1:04:21 PM UTC-4, wwa...@gmail.com wrote:
https://play.golang.org/p/LhOTUuTVqA
On Tuesday, November 1, 2016 at 12:50:09 PM UTC-4, Bill Warner wro
Yes it's just a fragment. Let me clean it up a bit, then I'll share a
playground link.
On 11/1/16 12:47 PM, Volker Dobler wrote:
Am Dienstag, 1. November 2016 02:07:49 UTC+1 schrieb wwa...@gmail.com:
Hello all,
I'm new to Go, and I have a question about identifying types as
they'r
