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

Remove buf redux #2179

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Remove buf redux #2179

wants to merge 2 commits into from

Conversation

kruss
Copy link
Collaborator

@kruss kruss commented Jan 27, 2025

This PR removes the chipmunk dependencies to buf_redux.

Copy link
Member

@AmmarAbouZor AmmarAbouZor left a comment

Choose a reason for hiding this comment

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

Great work 👍
I've found some minor issues with naming, formatting and missing comments alongside with a suggestion to avoid undefined behavior inside one of the proptests

@@ -0,0 +1,2 @@
# bufread
A buffered reader implementation in Rust with special behavior.
Copy link
Member

Choose a reason for hiding this comment

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

Do we need to provide more infos in the readme?

Comment on lines +29 to +31
let source_min_size = 100 * MAX_PACKET_LEN;
let buffer_max_size = 3 * MAX_PACKET_LEN;
let buffer_min_size = MAX_PACKET_LEN;
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure if having black_box() on the parser only is enough here. Can you try to have the values here black-boxed as well? I think we may get different result with them black-boxed

let source_min_size = black_box(100 * MAX_PACKET_LEN);
...

Comment on lines +116 to +118
unsafe {
vec.set_len(cap);
}
Copy link
Member

Choose a reason for hiding this comment

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

I think it's a good practice to write a safety comment on each unsafe code block link

&self.slice[self.start..self.end]
}

/// Sets the amount of newly read bytes.
Copy link
Member

Choose a reason for hiding this comment

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

Explanation about the returned value is missing. Also variable name num in code below could be more expressive

Comment on lines +173 to +195
pub fn write_from(&mut self, buffer: &[u8]) -> usize {
let size = min(self.write_available(), buffer.len());
self.write_slice()[..size].copy_from_slice(&buffer[..size]);
self.write_done(size)
}

/// Returns the number of currently available bytes for writing.
pub fn write_available(&self) -> usize {
self.slice.len() - self.end
}

/// Returns the current slice to write to.
pub fn write_slice(&mut self) -> &mut [u8] {
&mut self.slice[self.end..]
}

/// Sets the amount of newly written bytes.
pub fn write_done(&mut self, size: usize) -> usize {
let before = self.end;

self.end = min(self.end + size, self.slice.len());
self.end - before
}
Copy link
Member

Choose a reason for hiding this comment

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

Method names could be a little bit confusing because they do different kind of jobs but have same names:

  • write_available() and write_slice() are both getters
  • write_done() is a setter
  • write-from() actually writes the data into internal buffer.

I think having the function names starts with get, do, set or mark would be helpful to understand their purpose.
The same is for read function above as well

Comment on lines +73 to +85
assert!(payload_len <= MAX_PAYLOAD_LEN);

let packet_len = HEADER_LEN + payload_len;
let mut packet: Vec<u8> = Vec::with_capacity(packet_len);
unsafe {
packet.set_len(packet_len);
}

let header = (payload_len as u16).to_be_bytes().to_vec();
packet[0] = header[0];
packet[1] = header[1];

rand::thread_rng().fill_bytes(&mut packet[HEADER_LEN..]);
Copy link
Member

Choose a reason for hiding this comment

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

The bytes in the slice packet[2..HEADER_LEN] are uninitialized memory which may lead to undefined behavior. Is this intended? In that case we may need some comments in code here to explain the intention behind that.

Note: I would consider initialize the packet here with zeros instead the unsafe code since performance here isn't that relevant

policy::{DoRead, ReaderPolicy},
Buffer,
};
// TODO this duplicates: application/apps/indexer/processor/src/search/buffer.rs
Copy link
Member

Choose a reason for hiding this comment

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

Just to make sure this todo is intended to be done later and hadn't got forgotten 😄

impl<R: Read> BufRead for CancellableBufReader<R> {
fn fill_buf(&mut self) -> Result<&[u8]> {
if self.cancel.is_cancelled() {
return Ok(&[][..]);
Copy link
Member

Choose a reason for hiding this comment

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

This can be

            return Ok(&[]);

@@ -1,39 +1,62 @@
use buf_redux::{
Copy link
Member

Choose a reason for hiding this comment

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

Formatting seems to be broken on some files. Can you please run cargo fmt in indexer directory.
Running that on my machine introduced changes to the files:

  • addons/text_grep/src/buffer.rs
  • processor/src/search/buffer.rs
  • processor/src/search/searchers/mod.rs

impl<R: Read> BufRead for CancellableBufReader<R> {
fn fill_buf(&mut self) -> Result<&[u8]> {
if self.cancel.is_cancelled() {
return Ok(&[][..]);
Copy link
Member

Choose a reason for hiding this comment

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

Like the other file the formatting is off and this line can be

            return Ok(&[]);

@AmmarAbouZor
Copy link
Member

AmmarAbouZor commented Jan 30, 2025

@kruss @marcmo
It may be worth it to look into miri to see if we can use it since we are introducing unsafe code in this PR

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.

2 participants