Kontinuation commented on code in PR #586:
URL: https://github.com/apache/sedona-db/pull/586#discussion_r2796777787
##########
c/sedona-libgpuspatial/src/lib.rs:
##########
@@ -15,6 +15,537 @@
// specific language governing permissions and limitations
// under the License.
-// Module declarations
+use arrow_schema::DataType;
+use geo::Rect;
+
+mod error;
#[cfg(gpu_available)]
+mod libgpuspatial;
mod libgpuspatial_glue_bindgen;
+mod options;
+mod predicate;
+// Re-export to the users
+pub use error::GpuSpatialError;
+pub use options::GpuSpatialOptions;
+pub use predicate::GpuSpatialRelationPredicate;
+
+#[cfg(gpu_available)]
+mod sys {
+ use super::libgpuspatial;
+ use super::libgpuspatial_glue_bindgen;
+ use super::*;
+
+ pub type Result<T> = std::result::Result<T, GpuSpatialError>;
+
+ use std::sync::{Arc, Mutex};
+
+ use libgpuspatial::{
+ FloatIndex2DBuilder, GpuSpatialRefinerWrapper,
GpuSpatialRuntimeWrapper, SharedFloatIndex2D,
+ };
+ // To be used in the global state. We need to ensure these are Send + Sync
since they will be shared across threads.
+ unsafe impl Send for libgpuspatial_glue_bindgen::GpuSpatialRuntime {}
+ unsafe impl Sync for libgpuspatial_glue_bindgen::GpuSpatialRuntime {}
+
+ // -- Global State --
+ static GLOBAL_GPUSPATIAL_RUNTIME:
Mutex<Option<Arc<Mutex<GpuSpatialRuntimeWrapper>>>> =
+ Mutex::new(None);
+
+ // -- The Actual Implementation Struct --
+ pub struct SpatialImpl {
+ runtime: Option<Arc<Mutex<GpuSpatialRuntimeWrapper>>>,
+ // Index state is either building (Builder) or built (Shared)
+ index_builder: Option<FloatIndex2DBuilder>,
+ index: Option<SharedFloatIndex2D>,
+ refiner: Option<GpuSpatialRefinerWrapper>,
+ }
Review Comment:
I have some suggestions about the overall design of SpatialImpl. I am not
familiar with the special complexities brought by GPU programming, so there
might be some misunderstanding.
1. `SpatialImpl` needs to call `init()` to work properly. I think a more
Rusty idiom here is RAII: we implement a `try_new` that accepts `options:
GpuSpatialOptions`, and once the `SpatialImpl` is created it is ready to work.
No two-step construction.
2. `index` does not need to be a member of `SpatialImpl`.
`index_finish_building` can just consume the builder and return a
`SharedFloatIndex2D` value to the caller. `probe` doesn't actually use any
other field of `SpatialImpl` — it only needs the index — so it could take the
index as a parameter, or even become a method on `SharedFloatIndex2D` directly.
After doing this, `SpatialImpl` mostly won't need `Option` members anymore.
`runtime` and `refiner` get set in `try_new`, `index` is gone (returned to the
caller). The only one that still needs to be `Option` is `index_builder`, since
it's consumed by `finish` — but that's a clear lifecycle, not a "was init
called?" check. We get rid of all the `.ok_or_else(||
GpuSpatialError::Init(...))` ceremony in the refiner and probe methods.
If someone wants to defer initialization, they can use
`Option<SpatialImpl>`. The requirement of "only use it after initializing" just
becomes transparent.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
