Hacker News new | past | comments | ask | show | jobs | submit login

I did think of doing that, but from my understanding there is a slight performance hit from `defer`, and there is no other branch it could deadlock - or am I missing something here? Thanks either way!

Edit: Oh I just saw the addition to your comment - that is exactly what I was thinking of ^^




Defer overhead was mostly fixed in Go 1.14. From: https://go.dev/doc/go1.14

> This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly. As a result, defer can now be used in performance-critical code without overhead concerns.

EDIT: https://github.com/golang/go/issues/14939 I believe is the main tracking bug for this.


what about during a panic?


I think there was no performance hit on panic it was memory leak being fixed long time ago


They mean that the code could deadlock on a panic if the unlock isn't deferred. (At least, in the case where the panic ended up being handled somewhere and the process didn't just exit.)


Good point, thanks!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: