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
|
madolson
left a comment
There was a problem hiding this comment.
A couple of a high level things before diving deep into all the usage. Mostly looked good though.
| * 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.
| 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.
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.
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.
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.scriptc->flagged_as.scriptc->is.script_client
There was a problem hiding this comment.
@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.
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.
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 <739609084@qq.com> Co-authored-by: Ping Xie <pingxie@google.com> Co-authored-by: Madelyn Olson <madelyneolson@gmail.com> Co-authored-by: Viktor Söderqvist <viktor.soderqvist@est.tech>
8822d68 to
c224390
Compare
Signed-off-by: artikell <739609084@qq.com>
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.
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.
The bits should be 10, it causes ClientFlags to consume 8 more bytes now. Introduced in valkey-io#614. Signed-off-by: Binbin <binloveplay1314@qq.com>
The bits should be 10, it causes ClientFlags to consume 8 more bytes now. Introduced in #614. Signed-off-by: Binbin <binloveplay1314@qq.com>
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
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