[jni] Fix interface implementation deadlock on the main thread #2032
Conversation
PR HealthBreaking changes ✔️
Changelog Entry ✔️
Changes to files need to be accounted for in their respective changelogs.
API leaks
|
| Package | Leaked API symbols |
|---|---|
| jni | _ReferenceType _opaque_pthread_mutex_t _opaque_pthread_cond_t _Dart_FinalizableHandle |
This check can be disabled by tagging the PR with skip-leaking-check.
License Headers ✔️
// Copyright (c) 2025, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
| Files |
|---|
| no missing headers |
All source files should start with a license header.
Unrelated files missing license headers
| Files |
|---|
| pkgs/jni/lib/src/third_party/generated_bindings.dart |
| pkgs/objective_c/lib/src/ns_input_stream.dart |
| // | ||
| // When the current isolate is `null`, enter the main isolate that is pinned | ||
| // to the main thread first before invoking the `functionPtr`. | ||
| bool mustEnterIsolate = Dart_CurrentIsolate_DL() == NULL && mayEnterIsolate; |
There was a problem hiding this comment.
LGTM. Though I just noticed another possible edge case.
If we're on the owner thread (mayEnterIsolate is true), and not entered into the target isolate, but instead entered into a different isolate. Then we should exit that other isolate, enter the target isolate, run the callback, exit the target isolate, then enter the other isolate. Of course, there's always the possibility that the other isolate is not owned by this thread, so could be entered by another thread while we're in the target isolate. What a mess.
Anyway, none of that is possible ATM, but could come up in future. Maybe just add an assert that Dart_CurrentIsolate_DL() is either null or isolateId?
Closes #1908 using the proposed method in #1908 (comment).
I tested this locally, but we don't have the setup to automate Android tests on CI: #1155.