Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop go.uber.org/atomic in favor of sync/atomic #3443

Merged
merged 3 commits into from
Nov 1, 2024

Conversation

stefanvanburen
Copy link
Member

The primitives in sync/atomic are not as good as those in uber/atomic; happy to drop this.

The primitives in sync/atomic are not as good as those in uber/atomic;
happy to drop this.
Copy link
Contributor

github-actions bot commented Nov 1, 2024

The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).

BuildFormatLintBreakingUpdated (UTC)
✅ passed✅ passed✅ passed✅ passedNov 1, 2024, 7:44 PM

Comment on lines 407 to 424
// onceError is an object that will only store an error once.
type onceError struct {
err atomic.Value
}

// Store stores the err.
func (e *onceError) Store(err error) {
e.err.CompareAndSwap(nil, err)
}

// Load loads the stored error.
func (e *onceError) Load() error {
err, ok := e.err.Load().(error)
if !ok {
return nil
}
return err
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

took this from a bufstream PR; could use a raw atomic.Value inline, but this prevents needing to do the type assertion at the callsite. 🤷.

@stefanvanburen stefanvanburen marked this pull request as ready for review November 1, 2024 19:18
func (e *onceError) Load() error {
err, ok := e.err.Load().(error)
if !ok {
return nil
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a really bad situation - I need to review my Golang a bit, but if this is non-nil, this means that the thing that was stored was not an error on e.err, which would be a system error in itself.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I think for safety purposes you could move onceError to a different package so someone within this package can't muck with the e.err value directly (instead of using Store)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe, but that's not really what I'm saying - I'm saying that you are returning nil when ok == false, and ok should only be false if e.err.Load() is not of type error, which would be a really bad scenario (somehow something other than an error got stored on e.err. ok might also be falseife.err.Load()isnil`, but this is where my Golang is failing me - I assume that's the only thing that is meant to be captured here.

I would imagine that if you want to do something like this, you need to do:

errIface := e.err.Load()
if errIface == nil {
  return nil
}
err, ok := errIface.(error) 
if !ok {
  return syserror.Newf("expected error but got %T", errIface)
}
return err

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, that looks more technically correct to me - if you somehow stored something that isn't type error, you'd always just get nil currently. I'll update to your approach.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1a41b94 - feel free to change, just preferred the atomicValue var name.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm - I would probably update bufstream as well

@bufdev bufdev merged commit c26d758 into main Nov 1, 2024
10 checks passed
@bufdev bufdev deleted the svanburen/remove-uber-atomic branch November 1, 2024 19:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants