flutter_isolate does not actually spawn isolates since 2.1.0

[srmncnk]

What it says in the title.

The problematic commit

While using FlutterEngineGroup is a great idea in terms of memory consumption and sharing complex objects, it actually does not run in separate threads. I checked this by running this via ffi:

int64_t get_thread_id() {
  return (int64_t)syscall(SYS_gettid);
}

And it returned the same number for all the isolates spawned by flutter_isolate. For version 2.0.4 (which did not use FlutterEngineGroup yet), every thread id is a different number.

This is a bug and it should be addressed this way - behaviour in heavy-lifting apps drastically changes when doing a seemingly harmless upgrade from 2.0.4 to 2.10.

[nmfisher]

Thanks @srmncnk - let me take a look at this next week.

[castletaste]

up 🚀

[nmfisher]

@srmncnk I don't think this is a bug per se, there's never been a guarantee that different isolates will run on different threads (or that the same isolate will run on the same thread).

https://github.com/dart-lang/language/blob/main/working/333%20-%20shared%20memory%20multithreading/proposal.md#shared-isolate

Isolates are not threads even though they are often confused with ones. A code running within an isolate might be executing on a dedicated OS thread or it might running on a dedicated pool of threads. When expanding Dart's multithreading capabilities it seems reasonable to introduce more explicit ways to control threads.

I'm interpreting your issue as "using a FlutterEngineGroup still spawns an isolate, but this no longer creates a new thread, which degrades the performance".

Is that accurate? If so, did you encounter some specific performance regression?

@castletaste feel free to comment too.

[mkustermann]

Just to clarify: The flutter engine supports multiple UI isolates. It intentionally runs all of them on the same thread. It may be that the flutter embedding API you use here will create isolates the same way and will cause flutter engine to run them the same way as multi UI isolates.

Though any isolates spawned via dart:isolate APIs will run on a thread pool (where yes an isolate can run on the same thread as another isolate that just went to sleep and over time an isolate can run on different threads).

So if you have to create isolates from Java/ObjC/... and for whatever reason cannot use dart:isolate - you may make those spawned isolates do another Isolate.spawn() to ensure they run on the Dart VM's thread pool.

[srmncnk]

@castletaste @nmfisher @mkustermann Documentation says nothing about isolates potentially running in the same thread, only that they might run in different processes (source). In practice running a flutter_isolate v2.0.4 will spawn additional threads for each isolate, while running flutter_isolate v2.1.0 will make every flutter_isolate run in the same thread, making this essentially an expensive threadpool with size 1.

This, of course, produces big performance regression, if you do any kind of heavy lifting in the isolates.

At the very least, usage of FlutterEngineGroup should be a setting.

[rlueders]

I believe that I had observed the same problem when testing out the Dart UI Isolate package last year. At the time, that package (Dart UI Isolate) was using
FlutterEngineGroup while this package (Flutter Isolate) was not. There was over 60% performance reduction in the Dart UI Isolate package compared this one. I had opened an issue on that package here. I assume the latest version of both packages would exhibit the same 60% performance loss now.