Problems with try:
1 - hiding the return
2 - error decoration
The motivation behind this "issue" seems somewhat suspect. I get the
consensus the idea that people think the current state of the art `if err
!= nil { .. }` its verbose. I'd argue that isn't the issue with it. If we
want to
I've needed something similar. Its like a ManualResetEvent in C#, here is
some test code and the struct I use:
https://play.golang.org/p/mvSMwMZX51
Note running that on playground will timeout due to everything being
asleep, but this gets the idea across.
On Sunday, September 4, 2016 at 4:29:1
I needed something similar to ManualResetEvent in C# here is what I'm using
atm.
https://play.golang.org/p/UUyyK8ifku
This is attempting to be an edit, this example works better.
Also there is a helper method on the struct if don't want to wait forever
Wait has a timeout option. Although there
One more thing, if you want the wait condition to be grouped in a select{}
use the .Channel() method to get the channel. The Wait helper method does
this with a timeout, as an example. After the signal the channel is dead so
you have to use Channel() again to get the new one. If you're using it
Well you're waiting in the select... so yeah its going to be at the top.
The tickers themselves take up quite a bit of resources, in a little test
like this.
I adjusted your test to remove all the tickers, and got about 4x the speed.
I also set GOMAXPROCS to 1 gives it a better case against nod
On Wednesday, February 8, 2017 at 12:25:35 AM UTC-8, fwan...@gmail.com
wrote:
>
> If I use GOMAXPROCS=1, the result is acceptable.
>
Here are some more tests. This is scaling with number of cores, I assume
the slowdown is scheduler overhead, not really select cases.
2 core 2.4ghz VM
GOMAXPR
