search

shekohex / allo-isolate

Run Multithreaded Rust along with Dart VM (in isolate) 🌀
Apache License 2.0
120 stars 18 forks source link

when zero-copy is enabled, shall we mark `ZeroCopyBuffer` as deprecated, and provide a NonZeroCopyBuffer #40

Closed fzyzcjy closed 1 year ago

fzyzcjy commented 1 year ago

Just some nits that comes to my mind (not of high priority)!

temeddix commented 1 year ago

This was something that I also had in mind. though I was not sure what would be the better decision.

For the second choice, the name could possibly be CopyBuffer in my opinion.

fzyzcjy commented 1 year ago

For the second choice, the name could possibly be CopyBuffer in my opinion.

I think so. I just randomly created the name NonZeroCopyBuffer and it is surely not a name in production :)

temeddix commented 1 year ago

Or maybe we can allow the user to provide a callback closure that would be used after the Dart VM returned the memory. Right now, there is a hardcoded function that takes care of dropping the memory.

Say, we can take the bytes from Rust hashmap, give it to Dart as external data, and when Dart gives it back, Rust could store it back in the hashmap, with the closure provided by the user.

fzyzcjy commented 1 year ago

Looks interesting. However, I am worried whether this is useful: The time Dart VM returns the memory is non-deterministic. It will be called when GC iirc.

shekohex commented 1 year ago

Interesting.. Yes, I do think that we should just mark the code as compiler hint but not deprecated. I do not think there is a way to throw compiler warnings or hints. We could do a compiler error in that code path, However, a better way actually is that we entirely remove/disable the structure as in, only enable the ZeroCopyBuffer struct when the zero-copy feature gets enabled, this way it is more or less making the struct useless, which is okay. The only drawback of that it will make migration harder? Maybe.

For the other point about exposing the opposite of ZeroCopyBuffer (CopyBuffer) I do believe it does not make much sense. If you want to control what is ZeroCopied and what is not, you just remove/disable the feature and you have now the full control.

shekohex commented 1 year ago

Or maybe we can allow the user to provide a callback closure that would be used after the Dart VM returned the memory. Right now, there is a hardcoded function that takes care of dropping the memory.

Say, we can take the bytes from Rust hashmap, give it to Dart as external data, and when Dart gives it back, Rust could store it back in the hashmap, with the closure provided by the user.

You already could do that! There is the ffi module, it exposes all the low level things, you can always work on your implementation, struct wrappers, ..etc.