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
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
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
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
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
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
