а
А функция gomaxprocs работает только в контексте горутин?
Size: a a a
2020 April 16
T
А куда кусок конфы делся?
T
Ты выпилил сообщения наши?
T
в аналы
А, ок))
а
да
А если например взять цикл Фибоначчи , то как тогда внутри его создать горутины?
А
А если например взять цикл Фибоначчи , то как тогда внутри его создать горутины?
в каждом алгоритме есть свой ньюанс, на создание горутины и поддержку их работы нужны ресурсы, если действие которое ты сунешь в свой алгоритм будем занимать меньше времени чем создание горутиры и поддержка ее, то твоя многопоточность будет работать медленней чем если бы ты все делал последовательно
А
фибоначчи именно из тех которые не надо размножать
x
А если например взять цикл Фибоначчи , то как тогда внутри его создать горутины?
В процессе разработки, начинайте не с вопроса "как", а с вопроса "зачем".
Вот смотрите, как это просто:
— А если например взять цикл Фибоначчи , то зачем тогда внутри его создать горутины?
— Незачем
— Ок
Вот смотрите, как это просто:
— А если например взять цикл Фибоначчи , то зачем тогда внутри его создать горутины?
— Незачем
— Ок
а
В процессе разработки, начинайте не с вопроса "как", а с вопроса "зачем".
Вот смотрите, как это просто:
— А если например взять цикл Фибоначчи , то зачем тогда внутри его создать горутины?
— Незачем
— Ок
Вот смотрите, как это просто:
— А если например взять цикл Фибоначчи , то зачем тогда внутри его создать горутины?
— Незачем
— Ок
Ну я не много не понимаю суть - горутины это аналог proces_child в node js, когда просто делать так что бы данные выводились паралельно. Каналы нужны что бы синхронизировать данные в порядке очереди через каналы. Когда например используется 10 функций, и первая не завершилась все остальные не будут выведены
а
Например используем мы доп ядра, это дает скрипту возможность одновременно выполнять задачи независимо от каналов, или просто больше горутин?
а
Если в сестеме 4 ядра и поставить Макс пироц на 4, то тогда 4 функции одновременно будут выведены в консоль?
AY
9 женщин родят ребенка за 1 месяц
РБ
РБ
кто нибудь сталкивался с проблемой broken pipe в go?
есть сервис, в котором был не очень успешный фреймворк, в ходе одной задачи от фремворка избавились и теперь там чистый go http server
ну + mux gorilla для маршрутизации
так вот, при условии если клиент отвалился по собственному таймауту, т.е. прервал соединение со своей стороны - это приводит к падению процесса сервиса и broken pipe
есть сервис, в котором был не очень успешный фреймворк, в ходе одной задачи от фремворка избавились и теперь там чистый go http server
ну + mux gorilla для маршрутизации
так вот, при условии если клиент отвалился по собственному таймауту, т.е. прервал соединение со своей стороны - это приводит к падению процесса сервиса и broken pipe
А
кто нибудь сталкивался с проблемой broken pipe в go?
есть сервис, в котором был не очень успешный фреймворк, в ходе одной задачи от фремворка избавились и теперь там чистый go http server
ну + mux gorilla для маршрутизации
так вот, при условии если клиент отвалился по собственному таймауту, т.е. прервал соединение со своей стороны - это приводит к падению процесса сервиса и broken pipe
есть сервис, в котором был не очень успешный фреймворк, в ходе одной задачи от фремворка избавились и теперь там чистый go http server
ну + mux gorilla для маршрутизации
так вот, при условии если клиент отвалился по собственному таймауту, т.е. прервал соединение со своей стороны - это приводит к падению процесса сервиса и broken pipe
broken pipe указывает что соединение разорвано, но ни http server ни mux не должны ругаться на это, они приспособлены к этому и для них это стандартное поведение, я подозреваю что где-то в другом месте что-то падает (бд, очередь, ребит итд)
РБ
сейчас очень косвенно подтвердил только эту теорию - увеличили таймаут на клиенте и стало в разы меньше падений
А
Если в сестеме 4 ядра и поставить Макс пироц на 4, то тогда 4 функции одновременно будут выведены в консоль?
го по умолчанию использует все ядра, если не знаете что делаете или просто хотите сделать лучше, гомакспрок не меняйте никогда.
горутины в 90% случаях не нужны, ибо большинство фреймветков/библиотек уже их используют если надо
Го довольно быстрый язык, если у вас все работает приемлимо, лучше заняться другой работой, чем улучшать то что работает хорошо.
горутины в 90% случаях не нужны, ибо большинство фреймветков/библиотек уже их используют если надо
Го довольно быстрый язык, если у вас все работает приемлимо, лучше заняться другой работой, чем улучшать то что работает хорошо.
А
сейчас очень косвенно подтвердил только эту теорию - увеличили таймаут на клиенте и стало в разы меньше падений
проблема в том что клиентские соединения используют все остальные сервисы, по этому если клиент работает то и связанные "услуги" будут работать. Если у вас паника то пройдите по стеку в поиске ключевых слов, часто там можно найти источник