-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Allow embedders to specify their own task runner interfaces. #8273
Allow embedders to specify their own task runner interfaces. #8273
Conversation
WIP as we figure out if this interface is right and the unit tests have been added. |
4fdbb34
to
f484779
Compare
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request. Note to project maintainer: This is a terminal state, meaning the ℹ️ Googlers: Go here for more info. |
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request. Note to project maintainer: This is a terminal state, meaning the ℹ️ Googlers: Go here for more info. |
Currently, all Flutter threads are managed by the engine itself. This works for all threads except the platform thread. On this thread, the engine cannot see the underlying event multiplexing mechanism. Using the new task runner interfaces, the engine can relinquish the task of setting up the event multiplexing mechanism and instead have the embedder provide one for it during setup. This sceme is only wired up for the platform thread. But, the eventual goal is to expose this message loop interoperability for all threads.
f484779
to
ff7dbb7
Compare
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
1 similar comment
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
pending_tasks_[baton] = task; | ||
} | ||
|
||
dispatch_table_.post_task_callback(this, baton, target_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.
target_time values are based on the clock used by fml::TimePoint::Now()
. The embedder will need to expose an API that returns the value of that clock.
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 added FlutterEngineGetCurrentTime
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.
Note: I pretty much only looked at embedder.cc/h
SAFE_ACCESS(args, custom_task_runners, nullptr)); | ||
|
||
if (!thread_host || !thread_host->IsValid()) { | ||
FML_LOG(ERROR) << "Could not setup or infer thread configuration to run " |
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.
Nit: s/setup/set up/
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.
Fixed in followup CL since this has landed.
size_t struct_size; | ||
void* user_data; | ||
// May be called from any thread. Should return true if tasks posted on the | ||
// calling thread will be run on that same thread. |
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 had a hard time understanding how to reconcile this with the comment saying that running tasks on any thread other than the task runner's thread is undefined behavior. If the intent is that this can be used to check whether the thread it's called on is the task runner's thread, what about calling it something like is_task_runner_thread_callback
?
void* /* user data */); | ||
|
||
// An interface used by the Flutter engine to execute tasks at the target time | ||
// on a specified thread. There should be a 1-1 relationship between a thread |
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.
There should be a 1-1 relationship
Is this actually true? Couldn't multiple task runners share a thread?
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.
Not all thread configurations are known to be stable. This is an artificial restriction that we want to apply to embedder implementations for now. Once we verify that all thread configurations are stable, we can lift this restriction.
// embedder on the thread associated with that task runner by calling | ||
// |FlutterEngineRunTask| at the given target time. The system monotonic clock | ||
// should be used for the target time. The target time is the absolute time | ||
// from epoch (NOT a delta) at which the task must be returned back to the |
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.
the absolute time from epoch
fml::TimePoint says it measures time "since an arbitrary point in the past"; I'm not sure you can necessarily say it's from the epoch. I didn't check all of the implementations, but arbitrary monotonic clocks could easily be using boot time, for instance.
size_t struct_size; | ||
// Specify the task runner for the thread on which the |FlutterEngineRun| call | ||
// is made. | ||
const FlutterTaskRunnerDescription* platform_task_runner; |
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.
Should this be given a less generic name, if other thread/runners may be added here in the future?
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 think this is fairly specific to the Flutter engine and mentioned in the Wiki and other documentation.
@@ -715,6 +766,19 @@ FlutterEngineResult FlutterEnginePostRenderThreadTask(FlutterEngine engine, | |||
VoidCallback callback, | |||
void* callback_data); | |||
|
|||
// Get the current time in nanoseconds from the clock used by the flutter |
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.
s/Get/Gets/ (per Google commenting style for C++)
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.
Done.
FLUTTER_EXPORT | ||
uint64_t FlutterEngineGetCurrentTime(); | ||
|
||
// Inform the engine to run the specified task. This task has been given to |
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.
Informs
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.
Done.
flutter/engine@37947f9...c4d14a0 git log 37947f9..c4d14a0 --no-merges --oneline c4d14a0 Roll src/third_party/skia e4c67058ddb1..01a065884b7d (1 commits) (flutter/engine#8344) 5983b7a Roll src/third_party/dart ffee99d79b..cf32584870 (6 commits) 84c62b4 Build Windows shell (flutter/engine#8331) 6415277 Roll src/third_party/skia 8d2c19554e4a..e4c67058ddb1 (1 commits) (flutter/engine#8341) a011010 Roll src/third_party/dart 991c9da720..ffee99d79b (7 commits) 2098398 Cleanups to run_tests.sh script (flutter/engine#8337) 5c99138 Build GLFW from source for Linux shell (flutter/engine#8327) 6800245 Fix Windows build. (flutter/engine#8336) 6d8b836 Remove use of epoxy from Linux shell (flutter/engine#8334) 4efc321 Add super call in FLEView reshape (flutter/engine#8335) cb8eb80 Allow embedders to specify their own task runner interfaces. (flutter/engine#8273) The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md If the roll is causing failures, please contact the current sheriff (bmparr@google.com), and stop the roller if necessary.
…#8273) Currently, all Flutter threads are managed by the engine itself. This works for all threads except the platform thread. On this thread, the engine cannot see the underlying event multiplexing mechanism. Using the new task runner interfaces, the engine can relinquish the task of setting up the event multiplexing mechanism and instead have the embedder provide one for it during setup. This scheme is only wired up for the platform thread. But, the eventual goal is to expose this message loop interoperability for all threads.
…lutter#8273)" This reverts commit 9518151.
…lutter#8273)" This reverts commit 9518151.
Currently, all Flutter threads are managed by the engine itself. This works for
all threads except the platform thread. On this thread, the engine cannot see
the underlying event multiplexing mechanism. Using the new task runner
interfaces, the engine can relinquish the task of setting up the event
multiplexing mechanism and instead have the embedder provide one for it during
setup.
This sceme is only wired up for the platform thread. But, the eventual goal
is to expose this message loop interoperability for all threads.