Pro tip: optimise for correctness before performance.
--
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,
Thanks all, I don't use defer in a lot of the places to optimise and
minimise the lock time. I suppose looking at those points is probably the
safest place to start!
On Thursday, January 26, 2017 at 8:07:41 PM UTC, Dave Cheney wrote:
>
> Start with the basics like go vet which will spot a lock
Start with the basics like go vet which will spot a lock being copied by value.
Then check for each place you call Lock, there is a defer statement on th next
line.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group
2017. január 26., csütörtök 10:20:07 UTC+1 időpontban l...@pinkfroot.com a
következőt írta:
>
> Ok, why do you think I'm looking at too low a level, interested to
> understand!
>
> When I look at http://127.0.0.1/debug/pprof/goroutine?debug=2 most of
> the threads are in the semacquire state wa
Ok, why do you think I'm looking at too low a level, interested to
understand!
When I look at http://127.0.0.1/debug/pprof/goroutine?debug=2 most of the
threads are in the semacquire state waiting for a RWMutex lock to free up.
I'm trying to track down what/where it is stuck inside a current
On Thu, 26 Jan 2017 07:51:11 +
Lee Armstrong wrote:
> > Send HUP (kill -HUP pid or pressing Ctrl+\ on the terminal), when
> > the program is locked up, save the resulting stack trace, and
> > inspect. It'll list all running/blocked goroutines, and the point
> > of the wait, too.
> Thanks, I j
