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

deser: lazy CassRow construction #213

Draft
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

muzarski
Copy link
Collaborator

@muzarski muzarski commented Dec 3, 2024

Pre-review checklist

  • I have split my patch into logically separate commits.
  • All commit messages clearly explain what they change and why.
  • PR description sums up the changes and reasons why they should be introduced.
  • I have implemented Rust unit tests for the features/changes introduced.
  • I have enabled appropriate tests in .github/workflows/build.yml in gtest_filter.
  • I have enabled appropriate tests in .github/workflows/cassandra.yml in gtest_filter.

@muzarski muzarski marked this pull request as draft December 3, 2024 20:32
@muzarski muzarski self-assigned this Dec 3, 2024
@muzarski muzarski mentioned this pull request Dec 9, 2024
Other parts of the code make an assumption, that the pointer
representing `CassDataType` was obtained from an Arc allocation.

Take for example `cass_data_type_add_sub_type` - it clones an Arc.

This is a bug, that was fortunately detected by applying more restrictions
on the pointer types (introduced later in this PR).
The same bug as for collection types.
Again, if someone called `cass_data_type_add_sub_type` with
a data type obtained from `cass_column_meta_data_type`, it would
not be a pointer from an Arc allocation.
Weak::as_ptr() can return an invalid pointer. It can be even dangling (non-null).

It's safer to try to upgrade to an Arc. If upgrade was successful,
make use of RefFFI API to return a valid pointer. Otherwise, return
non-dangling null pointer.
Before this PR, the pointer was obtained from a valid
reference &CassFuture, which is totally fine.

However, I want to reduce the ways one can obtain such pointer.
For ArcFFI (shared pointers), I want them to be obtainable only in two ways:
- `ArcFFI::as_ptr()` which accepts an &Arc
- from the user, as a function parameter

This way, we are guaranteed that the pointer comes from a valid Arc allocation
(unless user provided pointer to some garbage, but there is no much we can do about it).
If we assume that user provides a pointer returned from some prior call to
API, we are guaranteed that it is valid, and comes from an Arc allocation (or is null).

I don't want to allow ArcFFI api to create a pointer from a refernce, to prevent
creating a pointer, from example from stack allocated object:
```
let future = CassFuture { ... };
let future_ptr = ArcFFI::as_ptr(&future);
```

This commit may not make much sense now, but all should be clear once
I introduce traits restricting the pointer types later in this PR.
This commit introduces a `CassPtr` type, generic over
pointer `Properties`. It allows specific pointer-to-reference conversions
based on the guarantees provided by the pointer type.

Existing `Ref/Box/Arc`FFIs are adjusted, so they now allow
interaction with new pointer type. You can say, that for a user of
`argconv` API, new type is opaque. The only way to operate on it is to
use the corresponding ffi API.
Disallow implementing two different APIs for specific type.
We also need to bump thiserror to 2.x.

Stopped matching against `BadQuery::SerializeValuesError` as it's
deprecated.
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.

1 participant