Threading migration

Fyne was originally created with the idea that threading should not get in the way of app developers. We aimed to solve concurrency problems so that all the API was safe to be called from any goroutine.

Unfortunately the performance impact in making every call thread safe was significant and we kept finding new possible issues and corner cases. Deadlocks and random issues could be attributed to these issues. In addition we found it was practically impossible to eliminate all race conditions in a complex codebase which led to us not being able to guarantee apps were race free.

Unaffected areas

• Data binding - As an API that is designed to communicate across boundaries of app areas will continue to work safely from any goroutine.
• Code creating new objects - Graphical items that have been created but not added to an app window can be manipulated on any goroutine. Thread safety matters once you interact with a window or the running application.

The future - from 2.6

Starting with Fyne release v2.6.0 there is support for guaranteeing race-free code and much better performance in applications through focusing on a single graphics and event thread. However it is possible that complicated applications cannot be transitioned without impact. It is possible that simply changing thread model could cause crashes or deadlocks - this document outlines how we are making the transition so that apps continue to work through the transition but developers will get all the benefits as soon as possible.

v2.6.0

• Move to the new threading model - events and graphics operations all happen on the same thread.

• The new fyne.Do API is added allowing developers to execute Fyne code from other goroutines.

• Fyne internals will detect when function calls are happening not he wrong thread and log accordingly, before continuing in a safe manner.

• Developers wishing to migrate to the new model fully can remove the checks, logs, and thread-switching being done internally (TODO - decide how)

v2.7.0

• Logging of thread errors will become more substantial (bigger warnings)
• Apps that have not migrated will log a warning on startup

v2.8.0 or v3.0.0 TBD

• The migration path will be disabled and apps not complying may crash or deadlock as a result of not being thread safe.
• Internal safety such as async Maps will be reverted to regular maps as we will assume single thread running of all graphical operations.