новички любят синхронный код код блокируя этим event loop, это катастрофа

callback hell?

он, родимый

вернее, нет

callback hell уже сто лет не актуален

это другая проблема

это вторая проблема, из которой проистекает первая

но она стоит острее

по крайней мере на си и плюсах

на древних компиляторах

против callback hell есть инструменты например Promises, на данный момент разрабатываю библиотеку асинхронного программирования для Qt: https://qbeon.github.io/QuickStreams/

уже столько сахара накрутили и паттернов, что коллбэк хэла уже давно нет

там ещё более продвинутый подход.. asynchronous programming in streams

в кутэ же система событий во фреймворке, зачем там асинхронная библиотека?

промизы/асинк эвэйт/реактивное программирование

это как в джава9? ленивые стримы?

в кутэ же система событий во фреймворке, зачем там асинхронная библиотека?

потому-что либо callback hell либо spaghetti code

это как в джава9? ленивые стримы?

не знаком с Java stream'ами, однако часто слышу

промизы/асинк эвэйт/реактивное программирование

верно, в QuickStreams я пошёл чуток дальше и добавил в reactive programming стримы стримы можно представить себе как Promise'ы на стеройдах (abortable, pausable, resumable, attachable, nested abstractions)

однако в Go такие подходы не нужны ибо тут green threads отменяют нужды в асинхронном коде

но поскольку в Go важно понимание синхронизации (multithreaded programming) походу выходит что event loop новичкам и разработчикам более высокого уровня на самом деле будет легче

на самом деле - седые строгие отцы не зря продвигают каналы для межгорутинного общения

канал довольно удачно прячет синхронизацию внутри

+1

удачно с точки зрения абстракции. с точки зрения производительности каналы так себе решение

в то время как race conditions и т.д. дебажить относительно сложно да и само по себе multithreaded программирование тема не из простых - асинхронное программирование легче дебажить и если блокировать loop то это заметно снижает производительность

в то время как race conditions и т.д. дебажить относительно сложно да и само по себе multithreaded программирование тема не из простых - асинхронное программирование легче дебажить и если блокировать loop то это заметно снижает производительность

а как заблокировать eventloop? про какой язык речь тут?

удачно с точки зрения абстракции. с точки зрения производительности каналы так себе решение

не спорю, однако это не меняет факт что channel это в конце концов тоже лишь mutex конструкция и рано или поздно чел встретится с проблемами синхронизации, например когда 2 рутины обрабатывают один map

а как заблокировать eventloop? про какой язык речь тут?

да очень просто, язык тут абсолютно не при чём, суть в том, что вся бизнес логика выполняется в одном потоке, если писать блокирующий код то это будет существенно тормозить процесс

поэтому код в эвент лупе нужно писать в асинхронном стиле (callbacks / promises & futures / streams / reactive)

не спорю, однако это не меняет факт что channel это в конце концов тоже лишь mutex конструкция и рано или поздно чел встретится с проблемами синхронизации, например когда 2 рутины обрабатывают один map

в 1.9 появился синхронизированный map, все видели?

да

в 1.9 появился синхронизированный map, все видели?

ну окей, тем не менее так или иначе в некоторых случаях синхронизировать код надо ручками, в event loop'е такой потребности нет в принципе

да очень просто, язык тут абсолютно не при чём, суть в том, что вся бизнес логика выполняется в одном потоке, если писать блокирующий код то это будет существенно тормозить процесс

при чем, не в каждом дают такую возможность - блокировать eventloop и вообще управлять им, но в целом по сути сказанного спорить не о чем

интересно, что java начинала с синхронизированных структур, но уже в 1.2 появились несинхронизированные версии - слишком велики были performance penalty

а go зашел с другой стороны, но все равно без двух версий не обошлось

при чем, не в каждом дают такую возможность - блокировать eventloop и вообще управлять им, но в целом по сути сказанного спорить не о чем

что значит "дают возможность"... тут же всё элементарно: если мы пишем слишком много кода для выполнения в одном цикле event loop'а - мы его неизбежно блокируем..

что значит "дают возможность"... тут же всё элементарно: если мы пишем слишком много кода для выполнения в одном цикле event loop'а - мы его неизбежно блокируем..

без конкретной реализации eventloop это разговор безадресный

без конкретной реализации eventloop это разговор безадресный

по вашему event loop можно написать таким образом, что вычисление числа фибоначчи до хрендевятисятой степени не сможет его заблокировать?))

в питоне eventloop заблокировать можно, в nodejs нельзя, если не использовать специально созданные ружья для выстрела в ногу)

по вашему event loop можно написать таким образом, что вычисление числа фибоначчи до хрендевятисятой степени не сможет его заблокировать?))

конечно, можно.

по вашему event loop можно написать таким образом, что вычисление числа фибоначчи до хрендевятисятой степени не сможет его заблокировать?))

оно заблокирует не evetloop а нить

в питоне eventloop заблокировать можно, в nodejs нельзя, если не использовать специально созданные ружья для выстрела в ногу)

нельзя?! это как?)))) как-раз таки в Node это проблема очень частая особенно для новичков

и если eventloop пулит такие задачи по тредам то все ок будет

eventloop перепендикулярен тредам, можно ввод-вывод сделать на эвентлупе, а колбеки на тредах

собственно java nio

нельзя?! это как?)))) как-раз таки в Node это проблема очень частая особенно для новичков

без sync-методов где это специально включено - никак

уровень доступа к eventloop в ноде нулевой, ты этой абстракцией не управляешь, а в питоне управляешь напрямую

оно заблокирует не evetloop а нить

возможно ты неправильно понял, речь идёт об использовании той или иной технологии с точки зрения программиста пользователя если написать в бизнес логике вычисление числа фибоначчи до уровня 10^999 то event loop повиснет, ибо бизнес логика выполняется не в нитях async IO, а в main thread'e и этого к сожалению многие особенно в начале не понимают и блокируют тем самым луп значитльно снижая производительность процесса

на thread pool'е выполняется код к которому ты как пользователь в основном не имеешь доступа, это реализация того или иного API

возможно ты неправильно понял, речь идёт об использовании той или иной технологии с точки зрения программиста пользователя если написать в бизнес логике вычисление числа фибоначчи до уровня 10^999 то event loop повиснет, ибо бизнес логика выполняется не в нитях async IO, а в main thread'e и этого к сожалению многие особенно в начале не понимают и блокируют тем самым луп значитльно снижая производительность процесса

и это не проблема eventloop, ибо заблокируется не только eventloop а весь поток

например filesystem API, network API и т.д. и т.п.

конкретно в ноде и в libuv есть пул потоков

конкретно в ноде и в libuv есть пул потоков

а доступа из js к нему нет

он там свою сомнительную магию делает

все блокируемые вызовы нода наверное выполняет в потоке из пула

операции с файлами и т.д.

конечно же у event loop'а есть thread pool для параллельного исполнения нескольких задач одновременно.. но речь идёт о БИЗНЕС ЛОГИКЕ

операции с файлами и т.д.

да, libuv через тредпул

если бизнес логика написана в синхронном стиле то это для event loop'а катастрофа

вот что собственно имеется ввиду

если бизнес логика написана в синхронном стиле то это для event loop'а катастрофа

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

заглушек нет, дети целы

да и вообще аналогия - сомнительный приём

хорошо что в го не эвентлуп с коллбеками

хороший специалист блокирующий код писать не будет, но их к сожалению не так много на самом деле потому-что сама идея асинх. прогр. пока ещё довольно нова в мейнстриме

расходимся

ERROR: S client not available

вот что собственно имеется ввиду

ну конкретно в ноде можно линтить вызов sync-методов и не давать их использовать, в питоне не давать работать с eventloop напрямую в продукте реализующим бизнес, писать асбтракции исключающие это

ну конкретно в ноде можно линтить вызов sync-методов и не давать их использовать, в питоне не давать работать с eventloop напрямую в продукте реализующим бизнес, писать асбтракции исключающие это

использование sync методов это лишь одна из возможностей блокировки которая на самом деле не так часта как другие, порой особенно в Node javascript используется для вычислений которые занимают слишком много cpu time блокируя loop

я и ваш го заблокирую легко, есть вроде бы GOMAXPROC - это сколько потоков отрабатывают горутины

достаточно сделать такое количество горутин с бесконечным циклом и все

я и ваш го заблокирую легко, есть вроде бы GOMAXPROC - это сколько потоков отрабатывают горутины

ну покажи как заблокируешь, шедулер же распланирует на доступный ресурс CPU, загрузить на 100% != заблокировать же

вроде бы переход с горутины происходит только в определенные моменты

при блокирующих вызовах или runtime.Gosched()

достаточно сделать такое количество горутин с бесконечным циклом и все

однако scheduler будет переодически свитчить между тасками, один таск не заблокирует другой

так-что аргумент не точен

однако scheduler будет переодически свитчить между тасками, один таск не заблокирует другой

в этом его и смысл

так-что Go заблокировать намнооого сложнее чем Node

не будет, если будет go func() { for {} }() * GOMAXPROC раз

ты уверен?

да, так и есть

у меня по этому поводу инфы нет, поэтому интересно откуда она у тебя

сейчас проверю

вообще это из теории, после прочтения Кернигана про го

если так и есть то не буду проверять

шедулер дедлает переключение на io not inlined func call

а это проверить же легко

я ровно один раз с этим столкнулся

просто 2 goroutine'ы запустить с разным console output'ом и обе подвесить в бесконечном цикле

если логировать выводить будет только один - всё ясно

просто 2 goroutine'ы запустить с разным console output'ом и обе подвесить в бесконечном цикле

И что будет?

по умолчанию GOMAXPROC = кол-ву ядер

я не до конца понял, что ты хочешь сделать, но похоже что это не заблокируется

тут скорее вопрос может ли go scheduler как системный scheduler переключать переодически рутины

если у тебя одноядерный процессор то заблокируется

если GOMAXPROC поставить на 1

не может и это вроде как киллерфича, меньше синхронизаций нужно

for testing purposes only

т.е. у тебя есть гарантия что переключение горутины будет происходить в определенные моменты