-
Notifications
You must be signed in to change notification settings - Fork 61
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
upd: kick notification on client side & fix: no kick option for local user #822
base: master
Are you sure you want to change the base?
Conversation
@IntegratedQuantum as of now we have three possible "disconnect" reasons right?
|
Yes. We could have more in the future though. |
shouldExitToMenu.store(true, .monotonic); | ||
exitNotification.store(exitData, .monotonic); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having two atomics like this is a problem.
The main thread could see the new value of shouldExitToMenu
, but still see the old value of exitNotification
, which causes a small chances of seeing an incorrect exit value.
Could you maybe just use one attomic of ?network.DisconnectType
to cover both in one?
@@ -21,6 +21,26 @@ const Vec3f = vec.Vec3f; | |||
const Vec3i = vec.Vec3i; | |||
const NeverFailingAllocator = main.utils.NeverFailingAllocator; | |||
|
|||
pub const DisconnectType = enum(u8) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't particularly like that this is just declared randomly at the beginning of the file.
Wouldn't it make more sense to move it into the disconnect
protocol?
fix: dont show kick for local user