Skip to content

ObjCBlock.fromFunction should return same block for same function #226

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

Closed
liamappelbe opened this issue Oct 19, 2022 · 6 comments
Closed
Assignees
Labels
lang-objective_c Related to Objective C support package:ffigen

Comments

@liamappelbe
Copy link
Contributor

Calling ObjCBlock.fromFunction twice with the same function should return the identical ObjCBlock. This would help a bit with #204, by creating fewer persistent handles.

It should be pretty easy to, using an Expando to attach the ObjCBlock to the Dart function. Then, inside ObjCBlock.fromFunction, we just check if the user's function has an ObjCBlock attached already, and return it if it's there.

@liamappelbe liamappelbe added the lang-objective_c Related to Objective C support label Oct 19, 2022
@liamappelbe liamappelbe self-assigned this Oct 19, 2022
@mkustermann
Copy link
Member

It should be pretty easy to, using an Expando to attach the ObjCBlock to the Dart function. Then, inside ObjCBlock.fromFunction, we just check if the user's function has an ObjCBlock attached already, and return it if it's there.

Doesn't that imply we have to keep the ObjC block artificially alive (by explicitly increasing refcount on it)? How would we know when to deref it again (to avoid leaking the block)?

Maybe this kind of optimization is more suitable for users, who may know if a callback will be needed many times, then the user code can re-use the ObjC block it already has instead of calling ObjCBlock.fromFunction?

@liamappelbe
Copy link
Contributor Author

We shouldn't be keeping it around any longer than before. If the first instance gets GC'd, then passing the same function again should return a new instance. The ref counting is pretty straightforward, and I have a unit test for the GC behavior. I'll include you in the PR.

@dcharkes
Copy link
Collaborator

dcharkes commented Oct 20, 2022

We shouldn't be keeping it around any longer than before. If the first instance gets GC'd, then passing the same function again should return a new instance. The ref counting is pretty straightforward, and I have a unit test for the GC behavior. I'll include you in the PR.

What about if we stick the closure in a toplevel variable?

(snippet taken from testcase in PR)

final func = makeAdder(4000);

void foo(){
  final block1 = ObjCBlock.fromFunction(lib, func);
  final block2 = ObjCBlock.fromFunction(lib, func);
}

Would we have GCed both blocks prior to dart-archive/ffigen#477 ? Now we would hold on to the block forever, correct?

@mkustermann
Copy link
Member

The issue with using Expando (amongst other things) is that the key may outlive it's value, thereby making us leak the values. The prime example is using a top-level tearoff of a function (such closures never die).

@liamappelbe
Copy link
Contributor Author

Yeah, good point. I suppose to do this properly I should use an explicit map from function to ObjCBlock and clean it up when the ObjCBlock is GC'd, but that has the same issue as #204.

@liamappelbe liamappelbe transferred this issue from dart-archive/ffigen Nov 15, 2023
HosseinYousefi pushed a commit that referenced this issue Nov 16, 2023
Bumps [actions/setup-java](https://github.com/actions/setup-java) from ea15b3b99cdc9ac45af1882d085e3f9297a75a8b to 5ffc13f4174014e2d4d4572b3d74c3fa61aeb2c2.
- [Release notes](https://github.com/actions/setup-java/releases)
- [Commits](actions/setup-java@ea15b3b...5ffc13f)

---
updated-dependencies:
- dependency-name: actions/setup-java
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
HosseinYousefi pushed a commit that referenced this issue Nov 16, 2023
Bumps [actions/setup-java](https://github.com/actions/setup-java) from ea15b3b99cdc9ac45af1882d085e3f9297a75a8b to 5ffc13f4174014e2d4d4572b3d74c3fa61aeb2c2.
- [Release notes](https://github.com/actions/setup-java/releases)
- [Commits](actions/setup-java@ea15b3b...5ffc13f)

---
updated-dependencies:
- dependency-name: actions/setup-java
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
@liamappelbe liamappelbe moved this to Backlog in ObjC/Swift interop Apr 10, 2024
@liamappelbe
Copy link
Contributor Author

I think this is not worth the effort, as it would provide minimal benefit with non-zero overhead.

@github-project-automation github-project-automation bot moved this from Backlog to Done in ObjC/Swift interop May 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lang-objective_c Related to Objective C support package:ffigen
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants