-
-
Notifications
You must be signed in to change notification settings - Fork 101
libprocessing ffi error handling #1293
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
libprocessing ffi error handling #1293
Conversation
| tracing = "0.1" | ||
| tracing-subscriber = "0.3" | ||
| bevy = { version = "0.16", no-default-features = true, features = [ | ||
| "bevy_render" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for wayland windowing we need to add "wayland" to the features array
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it's helpful, i can do it separately so i can actually test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we'll def need more fleshing out here, i think there's a bunch of other stuff we'll want too. we're just generally going to be doing the "annoying" bevy integration version where we fine grain select what we want. this is to keep the final dylib small for packaging. see also the recently merged bevyengine/bevy#21472 which could be helpful for us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that looks cool. maybe useful for per-target customization
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! I like the error approach too. And if we ever for whatever reason needed to share more details then we can just serialize more information.
I'm approving, but also curious about what things will look like, say, if they write an erroneous compute shader.
| tracing = "0.1" | ||
| tracing-subscriber = "0.3" | ||
| bevy = { version = "0.16", no-default-features = true, features = [ | ||
| "bevy_render" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that looks cool. maybe useful for per-target customization
| */ | ||
| public static long add(long left, long right) { | ||
| return processing_h.processing_add(left, right); | ||
| private static void checkError() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this means we would need to poll the rust side for any errors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup, this is a tedious consequence of ffi code. there are a few different c-style error patterns you can use, but they're all pretty manual. rust exceptions (panics) can't cross the ffi boundary (doing so is undefined behavior).
realistically, we'll probably only end up having like 20ish ffi functions. if we had hundreds, i'd suggest writing an annotation processor or some other kind of reflection magic in java to automate this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay and there is no way from Rust to push an event into Java?
i think we'll def run into situations like this. what i'd propose is that we write a struct ValidationResult {
error_code: u8,
data: *const c_void,
}in rust applications, you typically will bubble up on the java side, we're using unchecked exceptions. right now it's just a general "something went wrong" exception class, but we could totally add an error code in addition to message and sub-type more on the java side if we do want to throw something like |
Sets up basic bevy
Appinitialization and cross-FFI error handling.Our strategy here is the following: Java should do any validation necessary before calling into the FFI layer. Errors are assumed to be unrecoverable and evidence of us doing something wrong. So we don't return error codes or anything but just check the error status as a string so we can at least throw a helpful exception for bug reports.