DM
Вы знания лучше проверяйте у своих подчиненных. А если в чате кто-то ошибается его нужно поправить а не херней страдать
Я и задал наводящий вопрос
Size: a a a
2020 July 25
DS
Я и задал наводящий вопрос
дак какой у нас планировщик в 1.14 кооперативный или не кооперативный?
https://m.habr.com/ru/post/502506
https://m.habr.com/ru/post/502506
DM
дак какой у нас планировщик в 1.14 кооперативный или не кооперативный?
https://m.habr.com/ru/post/502506
https://m.habr.com/ru/post/502506
Официально asynchronously preemptible https://golang.org/doc/go1.14#runtime
DS
Официально asynchronously preemptible https://golang.org/doc/go1.14#runtime
Или как написано в драфте non cooperative, о чем я и написал
DM
Или как написано в драфте non cooperative, о чем я и написал
Вы не внимательны, я просил на что-то официальное, а вы непонятно на что ссылаетесь
DM
Или как написано в драфте non cooperative, о чем я и написал
Когда он был кооперативный?
ЛА
дак какой у нас планировщик в 1.14 кооперативный или не кооперативный?
https://m.habr.com/ru/post/502506
https://m.habr.com/ru/post/502506
Runtime.gosched было единственным признаком кооперативности
D
Привет.
Есть nodejs. У него внутри все основано на event loop. В частности при parse или stringify JSON нода это делает синхронно и забивает event loop пока не доделает его. Даже если вынести в другой поток работу с json, event loop все равно будет забит, когда в основной поток будет отдаваться результат и конструироваться объект.
Теперь касательно go. Имеет ли он такую же проблему при парсинге json ?
Или он не построен на event loop (libuv или что-то еще) ?
Java (и другие языки, где нет в ядре eventloop, типа C++, C#) могут парсить в отдельном потоке и просто передать в основной поток легковесную ссылку на готовый объект, что сокращает все расходы взаимодействия почти до нуля.
Есть nodejs. У него внутри все основано на event loop. В частности при parse или stringify JSON нода это делает синхронно и забивает event loop пока не доделает его. Даже если вынести в другой поток работу с json, event loop все равно будет забит, когда в основной поток будет отдаваться результат и конструироваться объект.
Теперь касательно go. Имеет ли он такую же проблему при парсинге json ?
Или он не построен на event loop (libuv или что-то еще) ?
Java (и другие языки, где нет в ядре eventloop, типа C++, C#) могут парсить в отдельном потоке и просто передать в основной поток легковесную ссылку на готовый объект, что сокращает все расходы взаимодействия почти до нуля.
Максимально тупой пример:
Если в жс ты в разных промисах будешь жсон парсить, луп заблочится, то есть промисы асинхронны но однопоточность никуда не делась
2 жсон на каждый по 1 сек. Как ни крути результат будет за 2 сек (если всякие node-cluster не юзать)
В Го горутины считай как промисы в жс, только горутины помимо асинхронности еще и у каждой свой «поток», то есть можешь парсить конкурентно хоть 100 жсон, они будут парситься одновременно
100 жсон на каждый по 1 сек. Результат будет ~1 сек
Если в жс ты в разных промисах будешь жсон парсить, луп заблочится, то есть промисы асинхронны но однопоточность никуда не делась
2 жсон на каждый по 1 сек. Как ни крути результат будет за 2 сек (если всякие node-cluster не юзать)
В Го горутины считай как промисы в жс, только горутины помимо асинхронности еще и у каждой свой «поток», то есть можешь парсить конкурентно хоть 100 жсон, они будут парситься одновременно
100 жсон на каждый по 1 сек. Результат будет ~1 сек
y
Максимально тупой пример:
Если в жс ты в разных промисах будешь жсон парсить, луп заблочится, то есть промисы асинхронны но однопоточность никуда не делась
2 жсон на каждый по 1 сек. Как ни крути результат будет за 2 сек (если всякие node-cluster не юзать)
В Го горутины считай как промисы в жс, только горутины помимо асинхронности еще и у каждой свой «поток», то есть можешь парсить конкурентно хоть 100 жсон, они будут парситься одновременно
100 жсон на каждый по 1 сек. Результат будет ~1 сек
Если в жс ты в разных промисах будешь жсон парсить, луп заблочится, то есть промисы асинхронны но однопоточность никуда не делась
2 жсон на каждый по 1 сек. Как ни крути результат будет за 2 сек (если всякие node-cluster не юзать)
В Го горутины считай как промисы в жс, только горутины помимо асинхронности еще и у каждой свой «поток», то есть можешь парсить конкурентно хоть 100 жсон, они будут парситься одновременно
100 жсон на каждый по 1 сек. Результат будет ~1 сек
не знаю, почему ты посчитал это тупой параллелью. Я довольно подробно написал, почему в js даже выделение в отдельный поток не принесет плодов. IO один на всю ОС
🅚
Подскажите, как решить одну диллему
Го же мультитредовый? И http запросы выполняются асинхронно?
У меня есть файл в который нужно писать инфу для юзеров (кастомные логи скажем так)
Можно как-то синхронизировать запросы записи данных юзера в этот файл?
Го же мультитредовый? И http запросы выполняются асинхронно?
У меня есть файл в который нужно писать инфу для юзеров (кастомные логи скажем так)
Можно как-то синхронизировать запросы записи данных юзера в этот файл?
DP
Подскажите, как решить одну диллему
Го же мультитредовый? И http запросы выполняются асинхронно?
У меня есть файл в который нужно писать инфу для юзеров (кастомные логи скажем так)
Можно как-то синхронизировать запросы записи данных юзера в этот файл?
Го же мультитредовый? И http запросы выполняются асинхронно?
У меня есть файл в который нужно писать инфу для юзеров (кастомные логи скажем так)
Можно как-то синхронизировать запросы записи данных юзера в этот файл?
Вариантов больше одного
AR
Можно сериализировать доступ через канал, можно через мютекс
DP
То ли вам канал нужен, то ли mutex, то ли вообще последовательное исполнение в одной горутине
🅚
Последовательную запись в файл
Допустим Вова и Юра захотели записать в одно время данные
Но нужно же их построить в одну очередь как-то...
Допустим Вова и Юра захотели записать в одно время данные
Но нужно же их построить в одну очередь как-то...
🅚
Я новичок в го, поэтому посоветуйте оптимальный вариант😅
DP
Мьютекс
ЕО
Только нужно помнить, что мьютекс залочит рутину на выполнение