-
Notifications
You must be signed in to change notification settings - Fork 694
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
Replace client flags to bitfield #614
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## unstable #614 +/- ##
============================================
+ Coverage 70.28% 70.30% +0.02%
============================================
Files 111 111
Lines 60215 60242 +27
============================================
+ Hits 42320 42353 +33
+ Misses 17895 17889 -6
|
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.
A couple of a high level things before diving deep into all the usage. Mostly looked good though.
src/sort.c
Outdated
@@ -308,7 +308,7 @@ void sortCommandGeneric(client *c, int readonly) { | |||
* The other types (list, sorted set) will retain their native order | |||
* even if no sort order is requested, so they remain stable across | |||
* scripting and replication. */ | |||
if (dontsort && sortval->type == OBJ_SET && (storekey || c->flags & CLIENT_SCRIPT)) { | |||
if (dontsort && sortval->type == OBJ_SET && (storekey || c->script)) { |
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.
if (dontsort && sortval->type == OBJ_SET && (storekey || c->script)) { | |
if (dontsort && sortval->type == OBJ_SET && (storekey || c->bitflags.script)) { |
The refactor that removes the "flag" makes many of these variables quite a bit harder to read, since c->script seems more likely to indicate the script it's running than if it's a script client.
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 like c->bitflags.script
. The bitflags
part doesn't bring additional value and makes the code hard to write/read IMO. Can we consider c->is_script_client
instead?
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 like c->bitflags.script. The bitflags part doesn't bring additional value and makes the code hard to write/read IMO. Can we consider c->is_script_client instead?
I think is_script_client only makes more sense if that is the only accessor method, but that isn't the case. bitflags makes it clear it is a wrapper structure around a bit of lower level flags. (If space wasn't a concern bitflags.is_script_client also seems ok to me).
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.
It's an anonymous union, nice!
I can agree with Ping that bitflags
(as in c->bitflags.script
) looks a bit ugly. It exposes too much about the internal representation. Can we find another name?
c->flags
is all flags, but with the bitfield we access one flag at a time, so how about something singular or boolean-like....
c->flag.script
c->flagged_as.script
c->is.script_client
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.
@PingXie Can you chime in here, I don't have a strong opinion and am happy to defer to whatever you think is clear.
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.
c->flag.script
I like this one.
Originally I was hoping to just go with an anonymous struct but now I notice that we actually need a named struct in places like acceptCommonHandler
.
I think we are aligned directionally. @artikell , do you mind updating bitflags
to flag
? I will work with you to get this PR into Valkey 8.0
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.
Sure, I think we will come this week to complete these processes.
I agree, so I have fixed the known problem. Let's see if we really need to make such modifications in the future. The usage of bitfields is more user-friendly for debugging and code reading. However, for some batch operations, such as clearing data, passing between functions, and batch assignment, they can be quite cumbersome. |
7260eb4
to
8822d68
Compare
Signed-off-by: artikell <[email protected]> Co-authored-by: Ping Xie <[email protected]> Co-authored-by: Madelyn Olson <[email protected]> Co-authored-by: Viktor Söderqvist <[email protected]>
8822d68
to
c224390
Compare
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.
Thanks @artikell! Overall LGTM. Only 2 nitpicks
- I prefer
!c->flag.foo
to!(c->flag.foo)
- what do you think about
flags
vsraw_flag
?
Signed-off-by: artikell <[email protected]>
I hesitated about modifying the parentheses. Avoid increasing the burden on reviewers. But this is correct, I have made all the modifications. I tend to lean towards |
#define CLIENT_MONITOR (1 << 2) /* This client is a replica monitor, see MONITOR */ | ||
#define CLIENT_MULTI (1 << 3) /* This client is in a MULTI context */ | ||
#define CLIENT_BLOCKED (1 << 4) /* The client is waiting in a blocking operation */ | ||
#define CLIENT_DIRTY_CAS (1 << 5) /* Watched keys modified. EXEC will fail. */ |
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.
We lost these comments in this refactoring. Some of them may be useful I think. We can add them at the bit field some other time.
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.
Let's add them now :-) #718
The bits should be 10, it causes ClientFlags to consume 8 more bytes now. Introduced in valkey-io#614. Signed-off-by: Binbin <[email protected]>
The bits should be 10, it causes ClientFlags to consume 8 more bytes now. Introduced in #614. Signed-off-by: Binbin <[email protected]>
Signed-off-by: zhenwei pi <[email protected]>
This is a complete version of PR #592, with the core points being:
-Replacing bitflags with flags
-Supports a clientFlags type for passing parameters, such as acceptCommonHandler
-Retained flags for initialization