хмм, ясно

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

а еще можно в своих длинных циклах периодически звать https://golang.org/pkg/runtime/#Gosched

один раз так и пришлось делать

go же даже панику раньше кидал про dead lock если залочить все горутины

дедлок - это другое

это лайвлок

эту ситуацию отдетектить автоматически непросто

ну... в конце концов, так или иначе event loop и green threads на равных event loop выигрывает в моих глазах в плане простоты написания кода из-за полного отсутствия параллельности (дебажить легче, проблемы очевиднее и прятаться им негде) green threads выигрывают в производительности позволяя параллелить бизнес-логику но в учётом что пользователь отдаёт себе отчёт в правильной синхронизации потоков (дебажить такое относительно сложнее)

ну... в конце концов, так или иначе event loop и green threads на равных event loop выигрывает в моих глазах в плане простоты написания кода из-за полного отсутствия параллельности (дебажить легче, проблемы очевиднее и прятаться им негде) green threads выигрывают в производительности позволяя параллелить бизнес-логику но в учётом что пользователь отдаёт себе отчёт в правильной синхронизации потоков (дебажить такое относительно сложнее)

коллега, вы троллите? какая такая простота в колбеках?

многие считают наоборот - в го ты асинхронный код пишешь как синхронный

коллега, вы троллите? какая такая простота в колбеках?

callback'и уже давным давно никто не пишет ?

fetch-hell?

парни, вот расскажите, что думаете, Docker в прод тянуть надо или только для dev/test стоит юзать?

если у нас есть эвенты - есть и колбеки, бро

многие считают наоборот - в го ты асинхронный код пишешь как синхронный

однако обязан синхронизировать взаимодействие потоков, как не крути, race condition дебажить не айс

а если эвенты спрятаны- это не эвентлуп

однако обязан синхронизировать взаимодействие потоков, как не крути, race condition дебажить не айс

для этого флаг сборки race и сделали

парни, вот расскажите, что думаете, Docker в прод тянуть надо или только для dev/test стоит юзать?

Пажди, тут разборки идут по другой теме ))

рейс кондишн ты и на евент лупе с пулом тредов можешь сделать

если у нас есть эвенты - есть и колбеки, бро

я имею ввиду в callback стиле никто уже давно не пишет, современные подходы такие как promises или reactive + streams

коллега нам про однопоточный эвентлуп задвигает же

я имею ввиду в callback стиле никто уже давно не пишет, современные подходы такие как promises или reactive + streams

еще раз, есть эвент - есть его обработчик. который называется коллбэк

нет эвента - нет эвентлупа

рейс кондишн ты и на евент лупе с пулом тредов можешь сделать

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

и рейс получить так же легко, если только ты не на функциональном языке пишешь

еще раз, есть эвент - есть его обработчик. который называется коллбэк

утверждение что "callback это плохо" уже попросту неактуально, поскольку в стиле который порождате такие проблемы как callback hell и т.д. никто сейчас не пишет

я полностью согласен, что синхронный код в green thread'е читается легче, но тем не менее, асинхронное программирование тоже на месте не стояло последние годы

так чо там с докером?

так чо там с докером?

Пажди, ещё не закончили.

я полностью согласен, что синхронный код в green thread'е читается легче, но тем не менее, асинхронное программирование тоже на месте не стояло последние годы

ну асинхронно уже везде можно писать в синхронном стиле

ты в API шедулишь выполнение 2 функций, обе из которых работают допустим с одним и тем же глобальным динамическим массивом, евентлуп все это распараллеливает на пуле потоков и ты ИНОГДА видишь непредсказуемый результат

что может быть хуже?

ну асинхронно уже везде можно писать в синхронном стиле

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

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

ну почему псевдо?

потому-что читается сверху вниз но технически он асинхронен, лишь абстрагирован

я полностью согласен, что синхронный код в green thread'е читается легче, но тем не менее, асинхронное программирование тоже на месте не стояло последние годы

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

потому-что читается сверху вниз но технически он асинхронен, лишь абстрагирован

ну я про стиль же написания и чтения и говорю

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

вот да

ты в API шедулишь выполнение 2 функций, обе из которых работают допустим с одним и тем же глобальным динамическим массивом, евентлуп все это распараллеливает на пуле потоков и ты ИНОГДА видишь непредсказуемый результат

код твоей бизнес-логики тебе синхронизировать не нужно поскольку поток исполнения один единственный, то что происходит на pool'ах позади API тебя не касается, ты пользователь API

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

эвенты никто не прячет, имеется ввиду что обработка событий уже не описывается в callback стилле

код твоей бизнес-логики тебе синхронизировать не нужно поскольку поток исполнения один единственный, то что происходит на pool'ах позади API тебя не касается, ты пользователь API

смотря какой абстракции API)

смотря какой абстракции API)

если пользователь используя event loop сам должен ещё и thread pool'е заботиться то с архитектурой платформы что-то не так)))

разруливать эффективный control flow в любом eventloop тот еще ад

и везде это потребность не закрытая из коробки

если пользователь используя event loop сам должен ещё и thread pool'е заботиться то с архитектурой платформы что-то не так)))

в питоне так, гвидо считает что так и нужно

ну я про стиль же написания и чтения и говорю

http.get() .then(...) .then(...) .catch(...) вот тебе пример псевдо-синхронного кода, он читается как синхронный сверху вниз, последовательно, однако технически он асинхронный

ну и где тут эвентлуп?

http.get() .then(...) .then(...) .catch(...) вот тебе пример псевдо-синхронного кода, он читается как синхронный сверху вниз, последовательно, однако технически он асинхронный

ну я говорил что синхронный стиль асинхронного кода заставит его выполняться технически синхронно? вроде нет

ну и где тут эвентлуп?

event loop собственно и исполняет данный код

это все те же гринтреды, с явным указанием yield (он там, где точка)

когда вместо спагетти у тебя линейный await или go, то это радикально упрощает код

ну я говорил что синхронный стиль асинхронного кода заставит его выполняться технически синхронно? вроде нет

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

это все те же гринтреды, с явным указанием yield (он там, где точка)

ну да, корутины везде или генераторы если ниже

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

есть хорошее русское слово - последовательно

это все те же гринтреды, с явным указанием yield (он там, где точка)

нет, это не green thread, это декларативное определение обработчиков

в отличии от императивного - нет callback hell'а

есть хорошее русское слово - последовательно

последовательно - sequentially, да

в отличии от императивного - нет callback hell'а

есть зато control flow ад

есть зато control flow ад

поясни плиз

ну когда асинхронные цепочки нужно выполнять, часть строго друг за другом, часть одновременно, и так далее

это именно бизнес-логика в переложении на eventloop

и.. в чём проблема?

не совсем понимаю

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

в го такой проблемы нет

в питоне она колоссальна, в ноде тоже выражена очень

ERROR: S client not available

всё-равно не совсем понимаю, планирование? в каком плане "планирование"??

всё-равно не совсем понимаю, планирование? в каком плане "планирование"??

ну вот приходит тебе список из N задач, их надо выполнить асинхронно, но M задач из списка должны быть выполнены только после того как выполнятся все задачи определенного типа, а T задач сразу же после того как завершена хотя бы одна другого определенного типа.

кто разрулит это за тебя?

а в го кто за тебя это разрулит?

а с green thread'ами типа такого рода "планирование" отпадает?))

ты говоришь, что через отправку сообщений это сделать проще?

это часть бизнес логики

а с green thread'ами типа такого рода "планирование" отпадает?))

вообще-то да. ты просто пишешь последовательный код. где надо - ждешь, где надо - вызываешь синхронный обработчик

streams.join(firstTask(...), secondTask(...)) .attach(stream { streams.race(thirdTask(...), fourthTask(...)) .attach(stream.close()) }) .failure(...)

это подход со стримами... позволяет относительно просто описывает довольно сложный асинхронный control flow

коллега

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

это подход со стримами... позволяет относительно просто описывает довольно сложный асинхронный control flow

при всем уважении это не просто и увольте от такого

я же неоднократно утверждал что синхронный код на green thread'ах читается проще))) я ВОВСЕ не спорю с этим я лишь представляю control flow решения со стороны асинхронного подхода

в event loop'е синхронный код не попишешь

но и callback'и там давным давно уже неактуальны

почти в любой среде GUI и с Node теперь даже на сервере у нас event loop

я хочу так await loop.parallel(Job(a), Job(a), loop.series(Job(a1), Job(a2)))

и код писать приходится именно асинхронно

я хочу так await loop.parallel(Job(a), Job(a), loop.series(Job(a1), Job(a2)))

ну.. хоти)) что я могу сказать

ну.. хоти)) что я могу сказать

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

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

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

можно ли приостановить и продолжить или отменить во время исполнения async await ?

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

в каком языке и для каких операций?

можно ли приостановить и продолжить или отменить во время исполнения async await ?

да

да

как это выглядит?

но тонкости есть везде свои

как это выглядит?

task.cancel например в питоне

если там нить внутри то надо это поддерживать

в каком языке и для каких операций?

я на данный момент пишу реализацию для Qt Quick (языки: C++ & QML) самая первая проблема с которой мы тогда столкнулись это network filesystem API, а именно асинхронная по-чанковая загрузка больших файлов

task.cancel например в питоне

проблема в том, что если операция состоит из под-операций то тут всё сложнее.. а со стримами всё относительно просто стримы могут состоять из стримов в периоде

внутри одного стрима могут быть 4 последовательных из которых он состоит они могут быть либо atomic либо abortable