Giters

shekohex / allo-isolate

Run Multithreaded Rust along with Dart VM (in isolate) 🌀

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

fzyzcjy opened this issue · comments

commented

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

  • shall we mark ZeroCopyBuffer as deprecated - otherwise it is confusing as it is no-op
  • provide a NonZeroCopyBuffer - otherwise there is no way to test/use non-zero copy
commented

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.

commented

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 :)

commented

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.

commented

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.

commented

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.

commented

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.