-
Notifications
You must be signed in to change notification settings - Fork 443
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
Possible improvements to SegQueue #794
Comments
Thanks for the suggestions and sorry for the late reply.
IIUC, there is no problem with zero-initializing a type that all fields are zeroable but contain padding. However, since the padding is undef, it is UB to inspect it even if it is zero-initialized.
AFAIK, in Block::new, both cases will be lowered to memset on many platforms, so performance will not change. (codegen comparison with concurrent-queue that has adopted that approach for a long time).
I'm torn on this because in some cases users expect no allocation at initialization (like Vec::new).
+1
Helps for review are welcome!
It is hard to add new dependencies to tokio (I remember it took a long time to get approved to use socket2), I would not expect them to add crossbeam-queue as dependencies even if SegQueue is improved. Also, loom support is required for use with tokio. |
I've been trying to understand the
SegQueue
implementation to reply to #675. These are some notes I took along the way:crossbeam/crossbeam-queue/src/seg_queue.rs
Line 67 in b11f1a8
SegQueue::new
should pre-allocate a block to match theInjector
implementation and remove some initialization code frompush
andpop
.offset + 1 == BLOCK_CAP
into a variable with the explanation from the previous bullet point.crossbeam/crossbeam-queue/src/seg_queue.rs
Line 206 in b11f1a8
crossbeam/crossbeam-queue/src/seg_queue.rs
Line 229 in b11f1a8
crossbeam/crossbeam-queue/src/seg_queue.rs
Line 297 in b11f1a8
crossbeam/crossbeam-queue/src/seg_queue.rs
Line 300 in b11f1a8
LAP - 1
that would be clearer asBLOCK_CAP
I'm planning on looking into this stuff so that Tokio can use
SegQueue
: tokio-rs/tokio#2528. Given #746's lack of progress, my main concern is that any opened PR would just get ignored, so Tokio might end up copyingSegQueue
with its own fixes (which would be a bummer).The text was updated successfully, but these errors were encountered: