Threading model thoughts

[dweymouth]

As the discussions and planning for #4654 continue, I thought I'd try to sketch out a partial requirements list. I think whatever model is decided, it will need to be able to meet these criteria at a minimum, so this is a good starting point for evaluating designs:

The model needs to specify how the following things can be accomplished safely and race-free from a user-spawned goroutine. (This is a partial list)

1. Modify a widget's state, like setting Importance of a button, inserting text into Entry or changing a label's text
2. Modify a CanvasObject state, like changing the color of a canvas.Rectangle, or changing the content of a canvas.Text
3. Change a container's contents
4. Perform updates on a window like change its title or set it to hidden
5. Write a 3rd party widget that exhibits the same safety guarantees as the built-ins

To start, with the hypothetical single-threaded model where all APIs are invoked from the same goroutine, the answer for # 1-4 is:

If in a user-spawned goroutine, run

// API name tbd - this API puts the given func() into a queue to be invoked on the app goroutine
fyne.RunFromGoroutine(func() {  
    label.Text = "foo"
    window.SetTitle("foo")
    // etc - any Fyne API
})

If not in a user-spawned goroutine, we guarantee you will already be on the "app" goroutine (ie every callback from Fyne to user code occurs on this goroutine, so it is automatically safe to just directly invoke any API.

And the answer for # 5 is you don't have to do anything special, since you know your users will be calling your APIs from a single goroutine, because doing otherwise goes against the guarantees the model provides

[andydotxyz]

I'm not sure that this needed another issue to track the discussion - I would have thought either the issue where the work is ongoing, or a design document. But as it's here I will comment on what was added:

The above description covers how we could fix a lot of issues for the main usage (to migrate to a single thread) which was the work already begun and documented on #4654. However it assumes that anyone launching a goroutine is required absolutely to manage the thread lifecycle by calling extra methods to pass in. This is pretty much the easiest thing for us to do, but puts a large cognitive load onto developers that I have always intended to avoid and even promised that everything just works the way you think it should.

Perhaps we need to make a progressive approach,

1. Move to a single app thread to better synchronise all the internals
2. Provide a way to safely call into that API as a stop-gap
3. Find a great solution for developers to safely call any widget API from any thread
4. (Potentially) migrate widgets to a "fields are read-only except when set through a state setter" as discussed with Cedric in recent calls.

I think that covers everything and allows us to make progress quickly but move to the simplistic API nirvana over time...

[dweymouth]

I am happy with 1. and 2. together as a starting point. That will ensure absolute thread safety is possible while 3. and 4. are in design/discovery

[andydotxyz]

Given that scope I would be tempted to go with the naming fyne.RunFromGoroutine which fits within the other context switching "Run..." methods but also clearly shows why/when it should be called.

[dweymouth]

Sounds fine, it's slightly long but I agree in this case the verbosity is good because it makes it very clear what it is for