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

[fzyzcjy]

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

[temeddix]

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]

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]

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]

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]

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]

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.