Многопоточность в GUI

У приложения на Fyne есть поток-владелец: главный goroutine, который после ShowAndRun из каркаса второго урока перестаёт быть твоим и становится циклом событий. Он выбирает уведомления операционной системы, определяет, над каким объектом курсор или палец, вызывает твои колбэки и раз в кадр отрисовывает то, что помечено изменённым. С версии 2.6.0 договорённость ужесточилась: все события и колбэки тулкита исполняются в одном и том же goroutine — и обработчик кнопки, и слушатель настроек, и колбэк диалога из тринадцатого урока. Это даёт скорость и предсказуемость: внутри обработчика ты можешь спокойно читать и менять любые виджеты, гонок с самим собой не будет. Обратная сторона — твоя горутина, запущенная через go func(), живёт вне этого мира: для неё виджеты — чужая память без защиты. Русский запрос «fyne goroutines» — это вопрос о границе между этими двумя мирами и о мосте через неё. Граница простая: всё, что имеет отношение к экрану — SetText, Refresh, SetContent, Show, диалоги, заголовок окна, — живёт в главном потоке; всё, что умеет без экрана — сеть, файлы, расчёты, ожидания, — живёт где угодно. Мост — две функции из пакета fyne, о которых дальше.

Гонка данных — это когда два потока обращаются к одной ячейке памяти одновременно, и хотя бы один пишет. Для Label это выглядит невинно: горутина пишет в поле Text, а главный поток в тот же момент рисует виджет и читает то же поле. Что прочитает отрисовка — старую строку, новую или половину каждой — решает планировщик, и от запуска к запуску исход разный. Хуже того: запись строки не атомарна, и читатель может увидеть разорванное значение, а составные структуры — невалидную память. Для map и слайсов те же гонки кончаются фатальнее: рантайм Go умеет ловить одновременную запись в карту и убивает процесс. Дешёвого «поставить мьютекс на каждый виджет» в тулките нет намеренно: каждый вызов с локом раз за кадр на каждый объект из дерева — это умножение стоимости отрисовки на порядок, и ради этого Fyne выбрал контракт «один поток — один интерфейс» вместо повсеместных замков. Твоя страховка — детектор гонок: собери приложение через go run -race и гоняй сценарий с фоновыми задачами; детектор печатает стеки обоих участников спора. Он ловит только фактические совпадения по времени, поэтому сценарий стоит прогнать несколько раз и под нагрузкой — тишина одного прогона ничего не доказывает.

Обе функции-моста появились в версии 2.6.0 и живут в самом пакете fyne. fyne.Do(fn) ставит функцию fn в очередь главного потока и немедленно возвращается; главный поток исполнит её между текущим моментом и следующим кадром — обычно в пределах десятка миллисекунд. Русский запрос «fyne поток gui» почти всегда про эту функцию. Правила гигиены очереди: держи функцию короткой — пока она исполняется, интерфейс не рисует и не принимает ввод; собирай изменения пачкой в один Do вместо десяти мелких — каждая функция это прогон через очередь; и не рассчитывай, что вызов исполнится мгновенно — до кадра ещё дойти надо. Внутри fn ты снова в главном потоке со всеми правами: можно и SetText, и Refresh, и показать диалог. Внизу лестницы есть и технический этаж: fyne.Do — обёртка над Driver().DoFromGoroutine(fn, wait), где второй параметр и есть выбор между асинхронным и синхронным поведением; разработчику почти никогда не нужно звонить туда напрямую — знай, что этаж существует. А вот пара более удобных входов сверху: колбэки, которые тулкит вызывает сам, — события шестого урока, слушатели настроек девятнадцатого — уже приходят из главного потока, и оборачивать их не нужно; мост нужен только для горутин, которые создал ты сам.

Семнадцатый урок оставил жёлтую рамку с обещанием разъяснить — выполняем. Источник привязки хранит значение под мьютексом: Get безопасен откуда угодно. Но Set запускает каскад: слушатели получают DataChanged в той же горутине, где случился Set, и если среди слушателей виджеты — их обновление уедет из твоей горутины прямиком в нарушение правила. Поэтому формула канона: писать в источники из фона — только через fyne.Do(func() { src.Set(v) }); тогда и значение, и весь каскад разъезжаются из главного потока, как будто пользователь нажал кнопку. Это же правило спасает DataListener из семнадцатого урока: колбэк слушателя исполняется в горутине Set, так что фоновая запись без обёртки тихо превратит твой логгер в гонщика. Полностью асинхронная альтернатива — не пускать фоновые данные напрямую в источники, а передавать их каналом и читать в главном потоке, но для типовых задач fyne.Do короче и читаемее. Отдельный случай — time.AfterFunc и тикеры: колбэк таймера исполняется в горутине рантайма, а не в главном потоке, так что таймер — тоже клиент fyne.Do. Проверь себя вопросом: кто создал goroutine, из которой вызван код? Если ответ «не тулкит» — нужен мост.

fyne.DoAndWait(fn) — то же самое с одной разницей: вызывающая горутина ждёт, пока главный поток исполнит fn, и возвращается уже после обновления. Документация описывает окно исполнения честно: между моментом запроса и следующим кадром, то есть до ~15 миллисекунд ожидания. Когда ожидание оправдано? Когда следующий шаг горутины зависит от факта обновления: ты обновляешь буфер изображения и не хочешь начать новый тик, пока старый не отрисован; тесту нужно знать, что интерфейс уже увидел значение; два последовательных Do должны прийти строго в порядке написания кода. За это платишь синхронностью: горутина стоит, а главный поток в этот момент не рисует. И главное предостережение: DoAndWait — инструмент только для своих горутин. Если позвать его из обработчика кнопки, то есть из главного потока работающего приложения, получится классический дедлок: главный поток ждёт очередь, которую обслуживает он сам, а обслуживать её он сможет только выйдя из твоего обработчика. Окно замрёт намертво. Единственное исключение — вызов до старта цикла событий, когда главный поток ещё твой: тогда функция исполнится сразу, но в этом сценарии обычно ещё некому и городить горутины.

Три сценария покрывают девять из десяти бытовых задач. Таймер: time.NewTicker в горутине и fyne.Do на каждый тик — часы, автосохранение раз в минуту, обновление курсов; на выходе из приложения тикер стоит остановить — окно закрылось, а горутина продолжает тикать вхолостую, храни stop-канал или контекст. Сеть: обработчик кнопки дёргает go func(), внутри — запрос стандартным http.Get, ответ разбираешь в горутине, а в главный поток уезжает уже готовая строка или структура пачкой в одном fyne.Do; не гоняй сырые байты через очередь по кусочкам — одна функция, одно обновление. Отмена: длинная задача обязана уметь останавливаться — context.WithCancel из обработчика кнопки «Стоп», select в рабочем цикле на ctx.Done(), по завершении fyne.Do со статусом; горутина, которую нельзя остановить, переживает окно и портит следующий запуск. Что выносить не стоит: всё, что быстрее пары миллисекунд, — мост дороже самой работы; событие — быстрый обработчик — Refresh, пропорция из шестого урока, не отменяется. Что выносить обязательно: чтение больших файлов, фильтрацию тысяч строк, что угодно с time.Sleep, сетевые вызовы — всё, за что пользователь платит замороженным окном.

Прежде чем выпускать приложение с горутинами, пройди по списку. Каждая длинная операция — сеть, файл, тяжёлый расчёт — запускается из обработчика через go func(), и ни одна не исполняется в самом обработчике дольше пары миллисекунд. Каждое касание экрана из фона идёт через fyne.Do, а пачки изменений сгруппированы в одну функцию. Каждая фоновая задача останавливаема: контекст или stop-канал, проверка в цикле, и по закрытию окна ничего не тикает впустую. Кнопки, запускающие горутины, отключаются на время работы — двойной запуск одной загрузки это не ускорение, а гонка с самим собой. Общий между горутиной и интерфейсом состояние либо передаётся значением через fyne.Do, либо защищено — sync.Mutex или атомарные типы, — и ни одна переменная не живёт в двух мирах без защиты. Прогон под go run -race выполнен на сценарии с реальной нагрузкой, а не на пустом окне. И последнее: не плодить горутин без нужды — тикер, который обновляет подпись раз в минуту, можно заменить проверкой при событии; каждый лишний параллельный агент это будущая гонка, которую кто-то однажды будет ловить под детектором.

Теперь приложение многопоточно в обе стороны: интерфейс отзывчив, фоновые задачи возвращаются мостом, отмена встроена в каждую долгую операцию. Опора урока — шестой с правилом главного потока и пропорцией «событие — быстрый обработчик — Refresh», семнадцатый с жёлтой рамкой про Set из чужой горутины, тринадцатый с диалогами, которые тоже живут в главном потоке, и второй с каркасом ShowAndRun. Следующая тема — файлы: хранилище приложения fyne.Storage, URI со схемой file:// и диалоги выбора, чтение которых ты теперь обязан оборачивать в горутину, если файл большой. Канон склейки уже готов: открываешь файл — уходи в горутину, возвращаешься — через fyne.Do. Полный маршрут — на странице курса Fyne.