I believe that perhaps this could solve the problem of low-level audio API callbacks in the system that today cannot be called with dart ffi

@insinfo Only if the audio API calls those callbacks on the platform thread. Audio APIs often create their own internal thread dedicated to audio rendering, and in that case platform isolates wouldn't help.

I still have a problem with that

@liamappelbe I wanted to use the runOnPlatformThread function but it appears to be not defined.

I can see the platform_isolate.dart file defined in the dart:ui library:

However, it's missing in the ui folder:

Edit: I'm curious if this issue might be linked to the absence of an entry for platform_isolate.dart in the dart_ui.gni file.

The output of flutter --version:

Flutter 3.21.0-10.0.pre.57 • channel master • https://github.com/flutter/flutter.git
Framework • revision 3236957f02 (31 minutes ago) • 2024-03-20 01:00:24 +0800
Engine • revision 59138d5f8e
Tools • Dart 3.4.0 (build 3.4.0-247.0.dev) • DevTools 2.34.0-dev.5

Edit: I'm curious if this issue might be linked to the absence of an entry for platform_isolate.dart in the dart_ui.gni file.

Maybe. I'm not a regular contributor to the engine, so I'm not sure what plumbing is needed when a new file is added. I'm surprised this wasn't caught by CI though. @jason-simmons should I add platform_isolate.dart to dart_ui.gni?

Sent a PR to add it to dart_ui.gni: flutter/engine#51538

The Platform Isolate API is now available on the master channel.

I've tried calling the runOnPlatformThread function in a Flutter Counter app but the app crashed with this error:

[FATAL:flutter/fml/message_loop.cc(21)] Check failed: loop != nullptr. MessageLoop::EnsureInitializedForCurrentThread was not called on this thread prior to message loop use.

It doesn't matter what you do in the function that you pass to the runOnPlatformThread function. Even calling it this way crashes the app with the above error:

  void _incrementCounter() async {
    await runOnPlatformThread(() {});
    // ...
  }

What platform did this happen on?

From the screenshot in #136314 (comment) it looks like you're running on Windows.

The runOnPlatformThread API is not supported on embedders such as Linux and Windows that use a custom task runner for the platform thread (see flutter/engine#48551 (comment))

I'm planning to add a Flutter engine flag that embedders can use to indicate whether they support this API.

What platform did this happen on?

From the screenshot in #136314 (comment) it looks like you're running on Windows.

Yes, I tested this on Windows.

The runOnPlatformThread API is not supported on embedders such as Linux and Windows that use a custom task runner for the platform thread (see flutter/engine#48551 (comment))

I'm planning to add a Flutter engine flag that embedders can use to indicate whether they support this API.

I see. Thanks for the explanation.

@halildurmus What's your use case? Windows APIs aren't usually thread locked

@halildurmus What's your use case? Windows APIs aren't usually thread locked

I think I've found a Win32 API (ShowCursor) that needs to be called on the platform thread in order to work (see dart-windows/win32#313).

I've confirmed that it works (hides the cursor) if I call the API inside the Windows runner (windows\runner\main.cpp).

I suspect there may be many similar APIs in the Win32 API that need to be called on the platform thread.

Looked at this again and found a viable way to make the current platform isolates implementation work with the task runner design used on Linux and Windows.

Proposed a PR: flutter/engine#51573

Not entirely sure whether the changes made in flutter/engine#51573 were intended to completely resolve the problems on Linux and Windows but after trying again, I still encountered the same error. I even gave it a shot on Linux, but it didn't work there either.

No - that PR is not a complete solution.

There is still the issue of supporting embedders where the platform thread does not have a message loop (see flutter/engine#48551 (comment)).

With flutter/engine#51573 a call to runOnPlatformThread in a host_debug_unopt Linux or Windows desktop engine build will execute the function on the platform thread.

But that only works because an internal debugging feature (DebugTaskRunnerChecker) is creating a message loop on the platform thread. Production builds will not enable this, so platform isolate initialization will fail with the MessageLoop::EnsureInitializedForCurrentThread was not called assertion seen above.

The Linux and Windows embedders will need to solve this in order to enable support for platform isolates.

The message loop is needed because UIDartState is trying to install a callback that runs after each message in order to execute Dart microtasks. If platform isolates need to support microtasks, then the embedder must create a message loop on the platform thread and also run the loop and execute this callback.

So until this is resolved I think it makes sense to also add the engine flag that embedders can use to declare whether they support platform isolates.

Wondering if there's a design doc or summary of what this means to Flutter developers?

May I ask if after this feature is implemented, I will be able to call the native function from the thread where the win32 window was created?

For example, SetWindowSubclass for win32 can only be called from the thread that created the win32 window. SetWindowSubclass can not be used across threads.

So I can't do it with pure dart code at the moment, I need to use platform channels for that.

May I ask if after this feature is implemented, I will be able to call the native function from the thread where the win32 window was created?

The feature is already implemented (as runOnPlatformThread), but unfortunately it's only fully supported on iOS and Android. I think there's partial support on windows and linux (debug mode only). See Jason's comment for details.

I've split off the remaining bits of work into their own issues. Closing this now.