Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement support for creating isolate independent native functions code in dart:ffi #47778

Open
Tracked by #47772
mraleph opened this issue Nov 25, 2021 · 16 comments
Open
Tracked by #47772
Assignees
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends.

Comments

@mraleph
Copy link
Member

mraleph commented Nov 25, 2021

The idea of isolate independent native code is described in finalization proposal

@mraleph mraleph added the area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. label Nov 25, 2021
@mraleph mraleph changed the title Implement support for writing isolate independent code in VM Implement support for creating isolate independent native functions code in dart:ffi Nov 25, 2021
@mraleph
Copy link
Member Author

mraleph commented Nov 25, 2021

Assigning to myself for the initial design.

@dcharkes
Copy link
Contributor

Another use case for this is async callbacks: we could potentially compile a function using the Dart API turning a callback into Dart_PostCObject. (Instead of implementing that in the VM or as a way of implementing that in the VM.)

@itsjustkevin
Copy link
Contributor

@mraleph is this work complete sufficiently to close out the issue?

@mraleph mraleph assigned dcharkes and unassigned mraleph May 5, 2022
@mraleph mraleph added this to the August Release (Dart 2.18) milestone May 5, 2022
@mraleph
Copy link
Member Author

mraleph commented May 5, 2022

This is in early design stages.

@calvin2021y
Copy link

half year passed and only 2 month left to Dart 2.18 release, any update on this?

@mraleph
Copy link
Member Author

mraleph commented Jun 13, 2022

@dcharkes has done some initial prototyping and we have been discussing different approaches.

It currently looks possible that we decide against implementing isolate independent code as a embedded DSL and choose to follow cgo route instead - simplify bundling C/C++ code with the Dart packages as this would address the same problem in a more robust way. But the final decision is not yet made.

@dcharkes
Copy link
Contributor

@calvin2021y We have a prototype on https://dart-review.googlesource.com/c/sdk/+/246241/ if you know how to build the Dart SDK and want to try it out.

@calvin2021y
Copy link

@dcharkes has done some initial prototyping and we have been discussing different approaches.

It currently looks possible that we decide against implementing isolate independent code as a embedded DSL and choose to follow cgo route instead - simplify bundling C/C++ code with the Dart packages as this would address the same problem in a more robust way. But the final decision is not yet made.

I like this much better, will try the Dart SDK branch.

@jacobaraujo7
Copy link

Any update about this @calvin2021y ?

@MaryaBelanger
Copy link
Contributor

@dcharkes @mraleph will this be going into 2.19? Asking for documentation update purposes

@dcharkes
Copy link
Contributor

dcharkes commented Sep 19, 2022

@dcharkes @mraleph will this be going into 2.19? Asking for documentation update purposes

No. We're exploring bundling C/C++ code with Dart packages instead.

@mraleph mraleph removed this from the December Release (Dart 2.19) milestone Sep 19, 2022
@mraleph
Copy link
Member Author

mraleph commented Sep 19, 2022

Cleared the milestone to reflect the change in our plans.

@GZGavinZhao
Copy link

Side note, if you just need a finalizer to reliably free a pointer, this works without any extra C code for a guaranteed freeing of your native resources:

// filename: lib/src/utils/memory.dart

/// A generic [NativeFinalizer] to free any pointer by calling the C function
/// `free`. It's kind of like a workaround to combat the restriction of
/// [NativeFinalizer] (which only accepts a C function, not a Dart
/// function).
final freenalizer = NativeFinalizer(DynamicLibrary.executable().lookup('free'));

Then,

import 'dart:ffi';
import 'package:mypackage/src/utils/memory.dart';

class Foo extends Finalizable {
  Pointer<X> _ptr = calloc();
  Foo() {
    freenalizer.attach(this, _ptr.cast());
  }
}

@dcharkes
Copy link
Contributor

dcharkes commented Oct 3, 2022

Side note, if you just need a finalizer to reliably free a pointer, this works without any extra C code for a guaranteed freeing of your native resources:

// filename: lib/src/utils/memory.dart

/// A generic [NativeFinalizer] to free any pointer by calling the C function
/// `free`. It's kind of like a workaround to combat the restriction of
/// [NativeFinalizer] (which only accepts a C function, not a Dart
/// function).
final freenalizer = NativeFinalizer(DynamicLibrary.executable().lookup('free'));

Then,

import 'dart:ffi';
import 'package:mypackage/src/utils/memory.dart';

class Foo extends Finalizable {
  Pointer<X> _ptr = calloc();
  Foo() {
    freenalizer.attach(this, _ptr.cast());
  }
}

That is not entirely true. On Windows WinCoTaskMemFree needs to be used when using calloc from package:ffi. See dart-lang/native#910 for making an abstraction for this.

@Keithcat1
Copy link

How would you embed C++ code when compiling Dart as an AOT executable and when running in JIT mode?

@dcharkes
Copy link
Contributor

How would you embed C++ code when compiling Dart as an AOT executable and when running in JIT mode?

Currently, you bundle dynamic libraries.

  • In Flutter use the FFI plugin template.
  • In Dart standalone, use a bin/setup.dart script that downloads or builds your dynamic libraries. (Note your downstream users need to all run dart run yourpackage:setup before stuff works.

This is not ideal.

Future:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends.
Projects
None yet
Development

No branches or pull requests

8 participants