-
Notifications
You must be signed in to change notification settings - Fork 687
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
Require C11 _Atomics #490
Require C11 _Atomics #490
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## unstable #490 +/- ##
============================================
- Coverage 70.19% 70.17% -0.02%
============================================
Files 109 109
Lines 59905 59883 -22
============================================
- Hits 42050 42024 -26
- Misses 17855 17859 +4
|
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.
Looks good so far.
I think we can also wait for another changes which is in progress. It's is a change for I/O threads which will probably use atomic variables a lot.
My idea is that we replace all atomic{Get,Set,Incr} and also delete atomicvar.h in one PR just before Valkey 8 release candidate 1, when no new features will be added. Then, if some users have a problem when testing the release candidate, we can revert it before we release 8.0.
@madolson What do you think?
@zuiderkwast I guess i would prefer we do the C11 migration now. Then anyone who is building from unstable will be able to start relying on the new improvements. I would rather find out sooner that someone might still have build issues. |
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.
"c11-builtin" is what's used today when C11 atomics are used. We can also consider dropping this info field. |
@zuiderkwast I think we should just drop it since we're making C11 the standard. |
Ok, please mention it in the PR description that we're dropping the INFO field "atomicvar_api". It's a user-facing change. |
7e8380c
to
8b7cfa0
Compare
Signed-off-by: adetunjii <[email protected]>
Signed-off-by: adetunjii <[email protected]>
Signed-off-by: adetunjii <[email protected]>
8b7cfa0
to
08ce3ee
Compare
…ix/c11-atomics
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 think you can now rm src/atomicvar.h
.
Thanks for taking the time to work on my comments!
Signed-off-by: Samuel Adetunji <[email protected]>
…ix/c11-atomics
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.
LGTM
Thank you!
We need to remove all CI jobs for CentOS 7. They fail because it doesn't support C11. Shall we change these jobs to CentOS 8? I think the point is to have one of the oldest OSes that's still supported. (CentOS 7 is EOL in June this year.) |
Yeah. I think it's best to remove old CI jobs for CentoS 7. Let's fix that in another PR |
I don't like to merge a PR which breaks the CI. It affects the daily CI too. We can do it in a separate PR, but then we should merge that CI PR before we merge this PR. |
Okay sure. I’ll have a look at it
Get Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: Viktor Söderqvist ***@***.***>
Sent: Friday, May 17, 2024 12:33:39 PM
To: valkey-io/valkey ***@***.***>
Cc: Samuel Adetunji ***@***.***>; Author ***@***.***>
Subject: Re: [valkey-io/valkey] Introduce C11 _Atomics (PR #490)
I think it's best to remove old CI jobs for CentoS 7. Let's fix that in another PR
I don't like to merge a PR which breaks the CI. It affects the daily CI too. We can do it in a separate PR, but then we should merge that CI PR before we merge this PR.
—
Reply to this email directly, view it on GitHub<#490 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKXTHW3KXAVQZ235T2KQEZDZCXTJHAVCNFSM6AAAAABHSLAAJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJXGM4TQOJUGM>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
CentOS 8 is already EoL, it never got long term support from RHEL from the looks of it. CentOS also doesn't exist anymore, it was evolved into CentOS stream. We could try AlmaLinux 9 or CentOS stream 9 as a replacement. I pinged some folks, but my initial guess is to move to CentOS stream. EDIT: Ideally we should have a matrix and do CentOS stream 9 and AlmaLinux 8. AlmaLinux 8 will be maintained until 2029, so it seems like a great replacement for our CentOS 7 test. |
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've looked though this diff now. Looks good, but I think I spotted two typos.
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.
LGTM.
Don't merge until we have replaced CentOS 7 in CI jobs.
I documented what we should do about centos 7 here: #527, in case someone else has time to pick it up. |
Signed-off-by: Samuel Adetunji <[email protected]>
66dc020
to
5489fc2
Compare
Centos7 is still in the CI in this branch. I don't know how it happened. Did you merge latest unstable? You can use merge commits. No need to rebase and force-push. We'll squash-merge it anyway. |
Signed-off-by: Samuel Adetunji <[email protected]>
It should be fine now |
@zuiderkwast when can this be merged? |
Probably tomorrow. People are not working today. |
Actually we discussed it now and it seems fine to merge. 🚀 |
Closes #485