Комментарии 21
Хорошая статья, но есть несколько замечаний:
- time.After, как и Sleep и подобные им не работают так, как сказано в статье. Они не сработают "через 5 секунд", есть лишь гарантия "не менее чем через 5 секунд", в общем случае нет гарантии, что они когда-то сработают за конечное время. Это стоит знать и жить с этим.
- "анонимная горутина" — все горутины анонимны. Вернее было бы "горутина, исполняющая анонимную функцию"
В статье много допущений и придраться есть к чему.
Но в большинстве случаев time.After сработает так, как задумано.
А «анонимностью» автор просто разделяет горутины с обычными функциями и анонимными.
Но в большинстве случаев time.After сработает так, как задумано.
А «анонимностью» автор просто разделяет горутины с обычными функциями и анонимными.
Сработает, как повезет. Откуда допущение про «в большинстве случаев»?
Пройдите и расскажите сколько раз вам «повезло»
play.golang.org/p/wvOh1tjZ_31
Если мало, изучите вопрос глубже. Внезапно выясняется, что авторы стандартной библиотеки тоже очень рассчитывают на «везение».
github.com/golang/go/blob/master/src/context/context.go#L384
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.
```
У вас все в одной горутине.
Поскольку в 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 секунды.
Лучше запускать локально, чтобы не попасться на ограничения «песочницы».
Обращу внимание, что если в коде, имитирующем тяжелые вычисления, если sleep, now, fmt, то это может дать повод runtime golang на то, чтобы сменить исполняемую горутину и тогда таймер имеет шанс отработать корректно. Но в приведенном коде этого нет и мы получим забавный результат вроде 32 секунд до таймаута, вместо ожидаемой 1 секунды.
НЛО прилетело и опубликовало эту надпись здесь
Учитывая название, думал увидеть тут и картинки про mutex, atomic, deadlock, lockfree, waitgroup и пр. Однако автор оригинальной статьи ограничился сугубо каналами. Думаю, тогда в название неплохо бы как-то втиснуть каналы, например «Изучаем многопоточное программирование с каналами Go по картинкам». Ну и даже с каналами примеры не очень-то параллельные, хотя бы несколько воркеров читали бы из одного канала, чтобы как-то распараллелиться, а так…
Для серьезного изучения рекомендую shop.oreilly.com/product/0636920046189.do
Писать «изучЯй» в заголовке — это стыдоба.
Правильно — «изучАй».
Правильно — «изучАй».
НЛО прилетело и опубликовало эту надпись здесь
Если вам нужна синхронизация между горутинами, то чтение будет блокирующим. Если блокировки нужно избежать, следует использовать select-case.
В статье об этом написано.
В статье об этом написано.
Горутины и потоки — это разные вещи. Пока горутина ждёт канала, поток операционной системы освобождается и используется для исполнения других горутин.
В том-то и прелесть горутин, что мы пишем код в синхронном стиле с блокировками, а по факту всё ассинхронное, и потоки не блокируются.
Еще есть полезная close() закрывать каналы, и начинающим важно знать про sync.waitGroup, оно может помочь самостоятельно поразбираться как работать с горутинами..
А вообще, go манит низким порогом вхождения, но не так прост как пишут…
Теми же горутинами можно наплодить подпрограмм которые превысят лимиты открытых дескрипторов и приложение станет, и вместе с тем остальным будет мешать..
Go вроде простой, но нужно осторожно, а если в продакшне, тт лучше всего в контейнере изолировать.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Изучаем многопоточное программирование в Go по картинкам