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

Replace client flags to bitfield #614

Merged
merged 2 commits into from
Jun 30, 2024

Conversation

artikell
Copy link
Contributor

@artikell artikell commented Jun 9, 2024

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

Copy link

codecov bot commented Jun 9, 2024

Codecov Report

Attention: Patch coverage is 86.93790% with 61 lines in your changes missing coverage. Please review.

Project coverage is 70.30%. Comparing base (7415a57) to head (fac1adb).

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     
Files Coverage Δ
src/acl.c 88.89% <100.00%> (-0.01%) ⬇️
src/aof.c 80.00% <100.00%> (-0.06%) ⬇️
src/cluster.c 88.26% <100.00%> (ø)
src/cluster_legacy.c 86.05% <100.00%> (+0.16%) ⬆️
src/db.c 88.40% <100.00%> (-0.01%) ⬇️
src/functions.c 95.59% <100.00%> (+<0.01%) ⬆️
src/logreqres.c 72.72% <ø> (ø)
src/multi.c 97.10% <100.00%> (+0.02%) ⬆️
src/object.c 78.57% <100.00%> (ø)
src/script.c 86.61% <100.00%> (ø)
... and 21 more

... and 5 files with indirect coverage changes

Copy link
Member

@madolson madolson left a 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)) {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
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.

Copy link
Member

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?

Copy link
Member

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).

Copy link
Contributor

@zuiderkwast zuiderkwast Jun 25, 2024

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

Copy link
Member

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.

Copy link
Member

@PingXie PingXie Jun 26, 2024

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

Copy link
Contributor Author

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.

src/server.h Outdated Show resolved Hide resolved
src/debug.c Outdated Show resolved Hide resolved
@artikell
Copy link
Contributor Author

artikell commented Jun 9, 2024

A couple of a high level things before diving deep into all the usage. Mostly looked good though.

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.

@madolson madolson requested a review from PingXie June 12, 2024 15:33
@artikell artikell force-pushed the switch_bitfield branch 2 times, most recently from 7260eb4 to 8822d68 Compare June 30, 2024 06:52
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]>
Copy link
Member

@PingXie PingXie left a 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

  1. I prefer !c->flag.foo to !(c->flag.foo)
  2. what do you think about flags vs raw_flag?

src/blocked.c Outdated Show resolved Hide resolved
src/blocked.c Outdated Show resolved Hide resolved
src/blocked.c Outdated Show resolved Hide resolved
src/server.h Show resolved Hide resolved
@artikell
Copy link
Contributor Author

Thanks @artikell! Overall LGTM. Only 2 nitpicks

  1. I prefer !c->flag.foo to !(c->flag.foo)
  2. what do you think about flags vs raw_flag?

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 raw_flag, which can distinguish it from flag. If using flags, it is easy to confuse. And I think raw can be expressed as an unorganized space.

@PingXie PingXie merged commit e4c1f6d into valkey-io:unstable Jun 30, 2024
19 checks passed
#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. */
Copy link
Contributor

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.

Copy link
Member

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

enjoy-binbin added a commit to enjoy-binbin/valkey that referenced this pull request Jul 2, 2024
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]>
enjoy-binbin added a commit that referenced this pull request Jul 2, 2024
The bits should be 10, it causes ClientFlags to consume 8 more bytes now.
Introduced in #614.

Signed-off-by: Binbin <[email protected]>
pizhenwei added a commit to pizhenwei/valkey that referenced this pull request Jul 3, 2024
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.

4 participants