when zero-copy is enabled, shall we mark `ZeroCopyBuffer` as deprecated, and provide a NonZeroCopyBuffer about allo-isolate HOT 6 CLOSED

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

from allo-isolate.

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.

from allo-isolate.

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.

from allo-isolate.

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.

from allo-isolate.

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.

from allo-isolate.

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.

from allo-isolate.