4 ms·

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

by Thaxll 4y ago

You should probably defer mutex unlock() and not use naked returns: https://github.com/pojntfx/go-nbd/blob/main/pkg/backend/file.go#L17 https://github.com/pojntfx/go-nbd/blob/main/pkg/backend/file... Defering overhead is very small nowdays.

pojntfx 4y ago
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 ^^
- philosopher1234 4y ago
  what about during a panic?
  - pojntfx 4y ago
    Good point, thanks!
  - Patrickmi 4y ago
    I think there was no performance hit on panic it was memory leak being fixed long time ago
    - foldr 4y 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.)
- kyrra 4y ago
  Defer overhead was mostly fixed in Go 1.14. From: https://go.dev/doc/go1.14 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 https://github.com/golang/go/issues/14939 I believe is the main tracking bug for this.