Pull to refresh

Comments 21

Хорошая статья, но есть несколько замечаний:


  • time.After, как и Sleep и подобные им не работают так, как сказано в статье. Они не сработают "через 5 секунд", есть лишь гарантия "не менее чем через 5 секунд", в общем случае нет гарантии, что они когда-то сработают за конечное время. Это стоит знать и жить с этим.
  • "анонимная горутина" — все горутины анонимны. Вернее было бы "горутина, исполняющая анонимную функцию"
В статье много допущений и придраться есть к чему.
Но в большинстве случаев time.After сработает так, как задумано.
А «анонимностью» автор просто разделяет горутины с обычными функциями и анонимными.
Сработает, как повезет. Откуда допущение про «в большинстве случаев»?
Пройдите и расскажите сколько раз вам «повезло»
play.golang.org/p/wvOh1tjZ_31

Если мало, изучите вопрос глубже. Внезапно выясняется, что авторы стандартной библиотеки тоже очень рассчитывают на «везение».
github.com/golang/go/blob/master/src/context/context.go#L384
Вы серьезно не понимаете, почему в вашем примере «повезло»?
У вас все в одной горутине.

Поскольку в golang нет гарантий когда будет переключение на какую горутину, то при выполнении программы во множество горутин time.Sleep и After начинают выдавать результаты, отличные от ожидаемых. Что может печально сказаться если надо предоставлять жесткие гарантии, например по таймаутам.

Golang — прекрасный язык, но он прекрасен в 95% случаев, если не повезло попасть не в самые популярные случаи, то беда…

Ну и в исходниках читаем:
```
// Sleep pauses the current goroutine for at least the duration d.
```
Как пример, когда все не отрабатывает, как ожидалось: play.golang.org/p/DWe7seVJomL
Лучше запускать локально, чтобы не попасться на ограничения «песочницы».

Обращу внимание, что если в коде, имитирующем тяжелые вычисления, если sleep, now, fmt, то это может дать повод runtime golang на то, чтобы сменить исполняемую горутину и тогда таймер имеет шанс отработать корректно. Но в приведенном коде этого нет и мы получим забавный результат вроде 32 секунд до таймаута, вместо ожидаемой 1 секунды.
UFO just landed and posted this here
Спасибо, исправил.
Учитывая название, думал увидеть тут и картинки про mutex, atomic, deadlock, lockfree, waitgroup и пр. Однако автор оригинальной статьи ограничился сугубо каналами. Думаю, тогда в название неплохо бы как-то втиснуть каналы, например «Изучаем многопоточное программирование с каналами Go по картинкам». Ну и даже с каналами примеры не очень-то параллельные, хотя бы несколько воркеров читали бы из одного канала, чтобы как-то распараллелиться, а так…
Писать «изучЯй» в заголовке — это стыдоба.
Правильно — «изучАй».
Если вы только ради этого комментария, то опоздали.
UFO just landed and posted this here
Если вам нужна синхронизация между горутинами, то чтение будет блокирующим. Если блокировки нужно избежать, следует использовать select-case.
В статье об этом написано.
Горутины и потоки — это разные вещи. Пока горутина ждёт канала, поток операционной системы освобождается и используется для исполнения других горутин.
UFO just landed and posted this here
Допускаю, что вас минусуют не за вопрос, а за выбор лексики.
В том-то и прелесть горутин, что мы пишем код в синхронном стиле с блокировками, а по факту всё ассинхронное, и потоки не блокируются.

Еще есть полезная close() закрывать каналы, и начинающим важно знать про sync.waitGroup, оно может помочь самостоятельно поразбираться как работать с горутинами..


А вообще, go манит низким порогом вхождения, но не так прост как пишут…


Теми же горутинами можно наплодить подпрограмм которые превысят лимиты открытых дескрипторов и приложение станет, и вместе с тем остальным будет мешать..


Go вроде простой, но нужно осторожно, а если в продакшне, тт лучше всего в контейнере изолировать.

Горутинами и каналами он очень напоминает очереди из модуля multiprocessing в python. И тут реализация понятнее для начинающих

UFO just landed and posted this here
Sign up to leave a comment.

Articles

Change theme settings