а мы про асинхронщину говорим, это немного другое

(кстати, совершенно зря)

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

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

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

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

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

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

что противоречит вашему высказыванию про явное переключение контекста да?

там она совершенно не на виду

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

взаимоисключающие параграфы. Блокируют горутину != ведут себя как синхронные, как раз наоборот. Горутина блокируется до получения события, при этом не мешая выполняться другим. Это прям асинхронность-асинхронность

что противоречит вашему высказыванию про явное переключение контекста да?

отнюдь

взаимоисключающие параграфы. Блокируют горутину != ведут себя как синхронные, как раз наоборот. Горутина блокируется до получения события, при этом не мешая выполняться другим. Это прям асинхронность-асинхронность

Ааа, то есть обычная многопоточность - это тоже асинхронщина?

Ааа, то есть обычная многопоточность - это тоже асинхронщина?

нет, но поверх многопоточности можно ее реализовать

и будет да

вот в го как раз реализовали

Потому что замени в твоём сообщении "горутина" на поток и будет как раз многопоточность

ну так это не взаимоисключающие понятия же

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

а откуда ты знаешь что там асинхронный IO внутри?

любой человек может написать свой go runtime с классической многопоточностью и никто и не заметит подмены (по крайней мере сразу, без задействования весьма большого количества горутин)

а откуда ты знаешь что там асинхронный IO внутри?

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

любой человек может написать свой go runtime с классической многопоточностью и никто и не заметит подмены (по крайней мере сразу, без задействования весьма большого количества горутин)

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

я вообще про то, что там как бы код Go абстрагирован от всей асинхронщины

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

но не перестанет быть асинхронным

я вообще про то, что там как бы код Go абстрагирован от всей асинхронщины

ну тогда ты можешь свой asyncio на потоках написать и никто не заметит подмены

та же логика

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

Я начинаю терять связь с реальностью

чёт я запутался

Я начинаю терять связь с реальностью

я за тебя рад

у меня тут утиная типизация протекла немножко походу

чёт я запутался

ну, если я правильно понял твою предъяву, "по коду го не видно, что он внутри асинхронный". Так вот, встречная тема - по коду asyncio тоже непонятно, есть там потоки или нет.

ну это кстати скорее плюс чем минус Go

просто для меня go выглядит как синхронный язык с синхронными операциями

просто они синхронны не по отношению к потокам

а по отношению к горутинам

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

выглядит как синхронный код, плавает как синхронный код, крякает как синхронный код,

просто для меня go выглядит как синхронный язык с синхронными операциями

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

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

чёёё?

опять же "синхронизация" - это прям вот из многопоточности пришло

чёёё?

ну, например, ты знаешь select {} в го? каким боком он похож на синхронный код?

он очень синхронен

так select же блочит горутину

такой же, как и select в позиксе

так select же блочит горутину

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

но ведь в go фактически всё блочит горутину

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

но горутины-то при этом параллельно работают все равно

как и потоки

вообще на самом деле это я запутался

а про select-то тут причем? Он в каком месте "параллельно работает"?

а про select-то тут причем? Он в каком месте "параллельно работает"?

ну, строго говоря, ни при чем. А если докопаться - то каким образом вообще могут приходить РАЗНЫЕ события в одну и ту же точку в коде, если код не асинхронен? то-то и оно, что никаким

Дело в том, что походу про асинхронность особо нет смысла говорить в отрыве от IO. К примеру в англоязычной википедии есть как раз статься про асинхронный IO. То есть не про асинхронность, а именно про асинхронный IO. И там есть три примера: блокирующий синхронный, неблокирующий синхронный, неблокирующий асинхронный. И Go как раз добавляет четвёртый и самый удобный тип: блокирующий асинхронный.

позиксовый селект же как-то работает

Дело в том, что походу про асинхронность особо нет смысла говорить в отрыве от IO. К примеру в англоязычной википедии есть как раз статься про асинхронный IO. То есть не про асинхронность, а именно про асинхронный IO. И там есть три примера: блокирующий синхронный, неблокирующий синхронный, неблокирующий асинхронный. И Go как раз добавляет четвёртый и самый удобный тип: блокирующий асинхронный.

вполне себе имеет. Источником событий необязательно должен быть внешний мир

а блочится он именно на select

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

позиксовый селект же как-то работает

позиксовый селект асинхронный кагбэ

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

ок

я окончательно запутался

я наверно не очень понимаю разницу между "синхронным" и "асинхронным"

я окончательно запутался

да что непонятно-то? есть эвентлуп, есть корутины. Есть переключение контекста явное. Есть при этом i/o или нет его - это отдельный вопрос, в общем случая для асинхронности он не нужен

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

параллельность - это выполнение нескольких кусков кода параллельно. Асинхронность - это выполнение нескольких кусков кода НЕ последовательно, но необязательно параллельно

а асинхронным, если оно может "случиться" (и требовать обработки) в любой момент времени - чем бы ни был занят мой "синхронный" код в это время

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

ну, в целом так и есть, да

ок, то есть если есть селект на два события, но порядок этих событий неизвестен, то это называется асинхронным

понял

ок, то есть если есть селект на два события, но порядок этих событий неизвестен, то это называется асинхронным

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

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

обратное верно?

точнее не так даже

верно ли, что если мы не прыгаем непоследовательно в разные части кода для обработки, то это синхронно?

верно ли, что если мы не прыгаем непоследовательно в разные части кода для обработки, то это синхронно?

в целом да

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

то есть если я пишу на Go, без оператора select, то я пишу синхронный код?

поэтому многопоточность тоже может реализовывать асинхронность

правда тогда прыгает шедьюлер go

то есть если я пишу на Go, без оператора select, то я пишу синхронный код?

если ты пишешь на go без оператора go - тогда да, у тебя синхронный код :)

но и то есть нюансы внутренние

уф

и без селектов

Вы все это время разбирали, что асинхронность перпендикулярна многопоточности?

и без каналов

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

Вы все это время разбирали, что асинхронность перпендикулярна многопоточности?

скорее, спор о терминологии

но JS ни про какие потоки не знает

но JS ни про какие потоки не знает

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

неа

даже вм не знает походу

и часть асинхронных вещей реализует именно за счет многопоточности

только рантайм ноды

но JS ни про какие потоки не знает

А воркеры?

ну да, я про ноду сейчас

v8 не знает, наверное

А воркеры?

вот хз

а воркеры - это, вроде, процессы

просто у v8 вроде бы есть (точно была) такая "замечательная" особенность, как строго один интерпретатор на процесс