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

make writer/reader types owned #723

Closed
milyin opened this issue Sep 27, 2024 · 1 comment
Closed

make writer/reader types owned #723

milyin opened this issue Sep 27, 2024 · 1 comment
Labels
release Part of the next release

Comments

@milyin
Copy link
Contributor

milyin commented Sep 27, 2024

Describe the release item

The types z_bytes_writer_t, z_bytes_reader_t are copyable according to their names. But they wraps Rust types ZBytesWriter/ZBytesReader which are not copyable.
The behavior of parallel reading/writing to multiple readers/writers is not defined.
There should be one and only one reader or writer for z_owned_bytes_t at any moment.
So we have to:

  • make z_bytes_writer_t, z_bytes_reader_t owned to protect from copying
  • (not right now, but it would be nice to have) - fail on creation e.g. z_owned_bytes_writer_t if another one exists
@milyin milyin added the release Part of the next release label Sep 27, 2024
@milyin
Copy link
Contributor Author

milyin commented Sep 27, 2024

After discussion with @DenisBiryukov91 the following plan was proposed:

  • the writer becomes z_owned_bytes_writer_t. The construction of the writer (in append case) consumes z_owned_bytes_t with move operation. This guarantees that no other writer can be created for the same ZBytes. After finishing writing the function e.g. z_close_writer which consumes writer and constructs updated z_owned_bytes_t should be called
  • the reader remains as is, like e.g. z_slice_iterator_t. It's copyable, multiple readers for same z_owned_bytes_t are allowed

This proposal is similar to this attempt to fix the same issue in #675

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release Part of the next release
Projects
Status: Done
Development

No branches or pull requests

1 participant