-
Notifications
You must be signed in to change notification settings - Fork 704
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
Changes from 2 commits
a654eca
6f18be3
434eeb4
335c807
8a902ad
1766a28
89162f2
250255c
beed89f
c0c61bc
a578081
473bf61
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -39,6 +39,12 @@ but here are some more situations where they can be useful: | |
- Performing I/O, such as communicating with a database. | ||
- Handling a large volume of network requests. | ||
|
||
Also note a caveat due to a limit to the number of concurrently running isolates: | ||
|
||
- 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 ...) There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
||
## Implementing a simple worker isolate | ||
|
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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?