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

Add note regarding synchronous communication between too many isolates #6182

Merged
merged 12 commits into from
Nov 8, 2024
Prev Previous commit
Next Next commit
Clean up
  • Loading branch information
aam committed Oct 30, 2024
commit 6f18be39cde6ec1c0f96d96de3a0e41080f1e6d2
6 changes: 3 additions & 3 deletions src/content/language/isolates.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,9 +41,9 @@ but here are some more situations where they can be useful:

Also note a caveat due to a limit to the number of concurrently running isolates:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rephrase this as

"""
Synchronous blocking communication between isolates.

If isolates want to communicate synchronously they have to leave the safety of Dart and resort to using C code via FFI to do so. Special care must be taken in this circumstance due to the Dart VM imposing a limit on the number of isolates that can run in parallel. If the number of isolates that synchronously block in FFI calls exceeds that limit no other isolate can run. If those blocking isolates wait on another unscheduled isolate to act, then deadlock can occur. To avoid this situation (preventing other isolates from running & possibly deadlock scenarios) such blocking C code must take care of leaving the current isolate before performing the blocking operation and re-entering the isolate before returning from the FFI call (see ...)
"""

(especially concurrently -> in parallel - we can run thousands of isolates concurrently but not in parallel, i.e. at the same time)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This text sounds good, but did you mean for it to replace my version or you thought about adding it?


- The limit is not hardcoded to a particular number, it is calculated based on the Dart VM heap size available to the Dart application, can be considered to between 8 and 32 depending on the platform.
- This limit doesn't affect asynchronous communction between isolates via messages - you can have hundreds of isolates running and making progress. The isolates are scheduled on CPU in round-robin fashion and yield to each other isolate often.
- Attempts to do *synchronous* communication between isolates over the limit though will result in a deadlock.
- The limit is not hardcoded to a particular number, it is calculated based on the Dart VM heap size available to the Dart application, can be considered to be between 8 and 32 depending on the platform.
- This limit doesn't affect asynchronous communction between isolates via messages - you can have hundreds of isolates running and making progress. The isolates are scheduled on the CPU in round-robin fashion and yield to each other often.
- Attempts to do *synchronous* communication between isolates over the limit though may result in a deadlock.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... unless special care is taken (the C code that does synchronous communication would need to leave the current isolate before it blocks and re-enter it before returning to dart, see ...)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the comment, I added this. PTAL.


[Flutter]: {{site.flutter-docs}}/perf/isolates

Expand Down