-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
[vm/ffi] Support freeing Pointer.fromFunction
trampolines
#50610
Comments
The way the ObjC bindings are written at the moment, there are no per-Block function pointers. There's a couple of trampolines that are used by all the blocks. So this wouldn't really apply. There are 2 ways of constructing Blocks: from an ordinary Dart function, or from a native function pointer (which would usually be from Pointer.fromFunction). In the latter case, I suppose we could add a flag to the constructor that tells the Block that the function pointer was created by Pointer.fromFunction, and that the Block now owns the function pointer and should free it when it's destroyed. |
Right now the Only if we start associating state with What we will need is a mechanism for higher-level language bindings's to free dart-related state associated with their callbacks (e.g. ObjC blocks, Java objects that may refer to dart objects/closures). |
|
We should actually tell users to migrate. I've filed: |
Currently, we never free these trampolines. The argument being that we hand out a pointer to C and we don't know when C is done.
However, in C use cases where the user knows when they are done with it, they currently have no way to free the trampoline.
In Java (with
Runnable
) and ObjectiveC (withBlock
), we do know when we're done with a callback. Consequently,package:jnigen
andpackage:ffigen
could generate the calls to free the trampolines.The text was updated successfully, but these errors were encountered: