Hacker News Reader

You should probably defer mutex unlock() and not use naked returns: https://github.com/pojntfx/go-nbd/blob/main/pkg/backend/file...

Defering overhead is very small nowdays.

View on HN

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

what about during a panic?

Good point, thanks!

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

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.

Reply on news.ycombinator.com