NativeFinalizer

[modulovalue]

@liamappelbe could https://api.dart.dev/stable/2.18.4/dart-ffi/NativeFinalizer-class.html be used to simplify wasm/bin/setup.dart by removing the dependency on dart_api_dl.h and finalizers.c? Have you considered this new API?

[liamappelbe]

Yeah, we could probably migrate to NativeFinalizers and remove finalizers.c.

[modulovalue]

If and after #105 lands, the unused native calls and finalizer.c bindings + the native dart bindings should probably be removed? I hope you could do this part @liamappelbe since you have more domain knowledge around that area.

[modulovalue]

I've looked a bit into how Strings could be efficiently bridged across Wasm -> Dart and it seems like Dart_NewExternalXString in dart_api.h could help here. I don't see any alternative ways to efficiently do that (The goal would be to avoid having to copy the underlying memory into Darts heap).

More broadly, I'm wondering if we could manage to support Toll-Free bridging of important Dart types when compiling Dart to Wasm, and running that Wasm in Dart.

(Perhaps the whole infrastructure for bundling native code alongside wasmer shouldn't be removed just yet, even if it might not be needed without written-in-c-finalizers)

[modulovalue]

Status update: Migrating to dart provided finalizers would require bumping the lower bound to at least 2.17.0. Since everything works fine for now, this isn't urgent, but should probably be done in the future.

[modulovalue]

@liamappelbe did you succeed at fixing the flaky CI by migrating to native finalizers?
The status of #122 seems to indicate no. If so, do you have any insights into what else could be causing that issue?

[liamappelbe]

Native finalizers was a red herring. Turned out to be a bug in FFI. It's fixed now, but still failing on mac on older versions of the SDK, so I'll try excluding them. It seems that flutter_example_test has also started failing for an unrelated reason.

[modulovalue]

I'm glad to hear that, thank you.