go - Fyne的线程安全在哪里定义？

Question

我对线程安全的 promise 被Fyne(以及Go)所吸引。但是，现在我在阅读Go方面变得越来越好，我看到的事情使人们相信，整个API都不是线程安全的，也许从来就不是这样。因此，我试图确定“线程安全”在Fyne中的含义。

我正在专门看

func (l *Label) SetText(text string) {
    l.Text = text
    l.textProvider.SetText(text) // calls refresh
}

并注意l.Text也是一个字符串。 Go中的分配不是线程安全的，因此对我来说显而易见的是，如果两个线程在标签文本上进行争用，并且两个线程同时调用label.SetText，则可能会导致内存损坏。

也许有人会说:“但是你不会那样做。”不，但是我担心有人在编辑应用条目确定其内容需要替换所有条目文本时编辑条目的内容的情况-在我的应用中这是完全可能的，因为它支持多个用户通过网络同时进行编辑，因此，对各种小部件的更新都是异步进行的。 (请注意，我不在乎两个人同时编辑同一个Entry会发生什么；一个人的更改将丢失，我不在乎是谁。但是它一定不会导致内存损坏。)请注意，我可以采用一种方法要做的是让后台线程创建一个全新的Entry小部件，然后将其替换当前Box中的小部件。但是那个线程安全吗？

这不是我不知道如何使用 channel 序列化内容。但是我希望Fyne消除对它的需求(博客文章声称确实如此)。甚至使用 channel ，我也无法说服用户在某个后台线程对其进行更改，隐藏等的情况下以各种方式干预窗口小部件不会导致崩溃。也许所有被序列化的内容都是完全安全的，但是我不想找出并非如此的艰难方法，因为我将无法修复它。

Fyne显然很新，似乎有很多希望，但是文档似乎对细节没有帮助。在某处有更多信息吗？人们尝试过这个吗？

Answer 1

您在这里找到了一些比赛条件。有改进的计划，但是首先要获得新的“BaseWidget”需要1.2版本-并且仅在几周前才发布。

直接设置字段主要用于设置目的，因此不应以您说明的方式使用。也就是说，我们确实要支持它。基本的窗口小部件将很快引入类似于SetFieldsAndRefresh(func())的内容，这将确保所传递代码的安全性，并随后刷新窗口小部件。

Refresh()中确实确实存在种族。内部使用 channel 的目的是为了消除这种情况-但存在一些困难，例如多个goroutine调用它。这是我们新的BaseWidget代码可以帮助的领域-因为它们可以在内部自动锁定。使用此方法将是线程安全的，并且在将来的发行版中不会对开发人员进行任何更改。

到目前为止，API已经使开发人员不必担心线程和任何goroutine的工作-我们确实需要在内部进行工作以使其更安全-您是正确的。 https://github.com/fyne-io/fyne/issues/506