-
Notifications
You must be signed in to change notification settings - Fork 67
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
Comments
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 |
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? |
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). |
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. |
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>
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>
I think this is not worth the effort, as it would provide minimal benefit with non-zero overhead. |
Calling
ObjCBlock.fromFunction
twice with the same function should return the identicalObjCBlock
. This would help a bit with #204, by creating fewer persistent handles.It should be pretty easy to, using an
Expando
to attach theObjCBlock
to the Dart function. Then, insideObjCBlock.fromFunction
, we just check if the user's function has anObjCBlock
attached already, and return it if it's there.The text was updated successfully, but these errors were encountered: