我被 Fyne(以及 Go)的线程安全 promise 所吸引。但现在我越来越擅长阅读 Go，我看到的一些事情让人相信 API 作为一个整体不是线程安全的，也许从来就不是线程安全的。所以我试图确定 Fyne 中的“线程安全”意味着什么。
我正在专门查看
func (l *Label) SetText(text string) {
l.Text = text
l.textProvider.SetText(text) // calls refresh
}
并注意 l.Text 也是一个字符串。 Go 中的赋值不是线程安全的，所以对我来说很明显，如果两个线程争夺标签的文本并且同时调用 label.SetText，我可以预期内存损坏。
“但你不会那样做”，有人可能会说。不，但我担心有人编辑条目的内容，而应用程序线程决定需要替换所有条目的文本 - 这在我的应用程序中是完全可能的，因为它支持多个用户通过网络同时编辑，因此各种小部件的更新都是异步进行的。 (请注意，如果两个人同时编辑同一个条目，我不关心会发生什么；某人的更改将会丢失，我不关心谁的更改。但它一定不会导致内存损坏。)请注意，我可以采用一种方法采取的方法是让后台线程创建一个全新的 Entry 小部件，然后该小部件将替换当前 Box 中的小部件。但是这个线程安全吗？
这并不是说我不知道如何用 channel 序列化事物。但我希望 Fyne 能够消除对它的需求(一篇博客文章声称它确实如此)；即使使用 channel ，我也无法说服自己，当某些后台线程正在改变它、隐藏它等时，用户以各种方式干预小部件不会导致崩溃。也许所有这些都是在幕后连载的并且是完全安全的，但我不想通过艰难的方式找出它不是，因为我没有办法修复它。
Fyne 显然是相当新的，并且似乎有很多前景，但文档似乎缺乏细节。有更多信息可以在某处获得吗？人们尝试过成功吗？
最佳答案
您在这里发现了一些竞争条件。有改进计划，但 1.2 版本需要首先获得新的“BaseWidget” - 而该版本仅在几周前发布。
直接设置字段主要用于设置目的，因此预计不会按照您演示的方式使用。也就是说，我们确实想支持它。基础小部件很快将引入类似于
SetFieldsAndRefresh(func())的内容，这将确保传递的代码的安全性并随后刷新小部件。当前
Refresh()中确实存在一场竞赛。内部使用 channel 的目的是为了消除这种情况 - 但也存在一些问题，例如多个 goroutine 调用它。这是我们的新 BaseWidget 代码可以提供帮助的领域 - 因为它们可以在内部自动锁定。使用这种方法将是线程安全的，在未来的版本中开发人员无需进行任何更改。
到目前为止，API 使开发人员不必担心任何 goroutines 的线程和工作 - 我们确实需要在内部工作以使其更安全 - 你说得很对。 https://github.com/fyne-io/fyne/issues/506
关于go - fyne的线程安全在哪里定义的？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59737307/