@robert-ancell @jpnurmi can you give this PR a look please? I think there is a bug in it where the dispose method for the engine may now be called from a background thread. I've added a comment at that part above.

For some context, I don't have tests written yet but the idea is to make it so platform channels can be responded to on any thread. This PR should be close but has one potential bug I can see. Also, I have zero gtk experience so I might be doing something wrong.

My thought is the easiest fix would be to add a ref in the background thread and post a task on the platform thread to unref it. That would guarantee the dispose happened on the platform thread. Let me know what you think. Thanks!

I tried to think if there were other methods of doing this (for example, making an asynchronous function that would do the send in the main loop and return the result to the calling thread), but I think your solution is probably the most practical.

It would be nice if Flutter plugin developers would synchronize all their responses to the glib main loop but it is C, so people will try and use threads. 😢

@robert-ancell Thanks for taking a look! I'll clean it up.

It would be nice if Flutter plugin developers would synchronize all their responses to the glib main loop but it is C, so people will try and use threads. 😢

Yea, there is a usability aspect to this change, the other driving force was performance. The platform thread can become saturated (especially at startup) and the largest cost for platform methods is thread hops. If we make users jump back to the platform thread to respond to messages running on different threads they are jumping to the platform thread to almost immediately jump to the ui thread, which is wasteful and slow.

auto label is removed for flutter/engine, pr: 37689, due to - The status or check suite Linux Framework Smoke Tests has failed. Please fix the issues identified (or deflake) before re-applying this label.