«Дырявые абстракции».

псевдоблокирующий вызов.

Я в ваших го и тредах ничего не понимаю, но

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

А в жабоскрипте/питоне аналог файберов - это async/await, нет? Называть эти вызовы асинхронными?

Но, скажем, в OpenResty такого нет. Там важно знать, заблокируется ли нить или нет, потому что она одна.

Постой, разве у тебя путаница возникла не от того, что в го дофига тредовфайберов? Если в openresty такого нет, то откуда проблема?

Называть эти вызовы асинхронными?

Использование «синхронный»/«асинхронный» ту же путаницу вносит.

Если в openresty такого нет, то откуда проблема?

Там есть нечто, что они называют light thread. Они сделаны на корутинах Lua. В них можно соединиться с чем-нибудь по TCP и обмениваться данными. Код выглядит синхронным, но при этом не блокирует выполнение основного цикла Nginx. Таких light thread можно создавать много. При этом с точки зрения системы процесс однопоточный.

Использование «синхронный»/«асинхронный» ту же путаницу вносит.

Не вижу путаницы.

Использование «синхронный»/«асинхронный» ту же путаницу вносит.

Не вижу путаницы.

Опиши тогда этими словами read() для сокета, для стандартного режима и SOCK_NONBLOCK, и sock:receive() из openresty.

Если ты не в курсе, openresty это по сути Nginx с прикрученным к нему Lua. Много запросов могут быть в обработке сразу. Чтение из сокетов в обработчике одного запроса не тормозит другой. Но как бы тормозит текущий. Иными словами, можно считать, что sock:receive() не вернёт управление, пока оговорённый объём данных не будет получен.

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

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

Добавить еще один описательный признак, нет? Синхронный/асинхронный.

фиберами

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

асинхронный блокирующий вызов — если потоков > 1, то за счёт этого блокировка нивелируется, т.е. синхронность/асинхронность управляет конечной оценкой вызова, поэтому является внешним описательным признаком

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

синхронный блокирующий вызов

асинхронный блокирующий вызов

Слово «асинхронный» уже используется как аналог «неблокирующий»: https://en.wikipedia.org/wiki/Asynchronous_method_invocation

если потоков > 1, то за счёт этого блокировка нивелируется

Но ведь не только за этот счёт. Например, Nginx работает в один поток, но при этом держит тысячи соединений одновременно. Подвисание одного не влияет на другие.

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

Ну да. Проблема только в том, что люди неправильно понимают. Каждый раз в обсуждениях приходится заново договариваться, что значит «асинхронный». Это утомляет.

Похожая проблема есть со термином «сублимация». Для перехода между жидкостью и газом есть два термина: «испарение» и «кипение». А для перехода между твёрдым телом и газом есть «сублимация» и «сублимация». Можно попытаться зафиксировать термин для одного их процессов, назвав второй другим именем, или добавив ещё какое-нибудь слово. Но оба процесса уже называют «сублимацией», поэтому от путаницы так не убежать.

Golang, blocking

В го хттп или тсп запросы являются по умолчанию блокирующимися (в терминологии самого го). То что при этом может вызываться другая гороутина это дело десятое, сама гороутнина с вызовом будет заблокирована. Если мы хотим контролировать время блокировки можно использовать различные паттерны, например использовать механизм пакета context.

Слово «асинхронный» уже используется как аналог «неблокирующий»: https://en.wikipedia.org/wiki/Asynchronous_method_invocation

Это безграмотность. На линуксе почти всегда «Неблокирующий» это «синхронный».

если потоков > 1, то за счёт этого блокировка нивелируется

Но ведь не только за этот счёт.

Это был пример реализации асинхронности.

Может, тогда по аналогии с моделями вычисления: энергичный vs. ленивый? Ленивый блокирующий вызов, энергичный блокирующий вызов. Правда, для неблокирующих вызовов критерий ленивый/энергичный плохо применимы.

А вот фиг его знает. В высокоуровневых языках такое встречается повсеместно и относится далеко не только к вводу-выводу в сокеты или файлы.

Может добавить префикс и получить что-то вроде «thread-blocking» («потоко-блокирующие»), «fiber-blocking» («волокно-блокирующие»), «asynchronous» («асинхронные»)?

Это безграмотность. На линуксе почти всегда «Неблокирующий» это «синхронный».

Что значит почти? Да и операция может быть асинхронной, даже если вызов функции синхронный. Для пояснения опять нужен абзац текста, потому что все понимают слово «синхронный» по-разному.

«thread-blocking», «fiber-blocking»

О, а это звучит неплохо. Спасибо!

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

А это вообще как понять? Данный приходят в сокет или в фибер? На шизофазию похоже :)

А это вообще как понять? Данный приходят в сокет или в фибер?

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

Наверное, это сложно понять, если не сталкивался.

Работал когда-нибудь с неблокирующим IO на сях? Вот примерно так, только вся морока с возобновлениями скрыта рантаймом.

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

Время скачет и в обычных потоках. Запустил read() сейчас, проснулся — а уже пару секунд прошло. Или пользователь послал SIGSTOP, и всё вообще повисло на неопределённый срок.

Время монотонное, и это уже хорошо. Требовать чего-то большего смысла нет.

Асинхронный?

Ну, да. Это я больше о моделировании.

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

Асинхронный?

Чуть ли не автоматически воспринимается как «неблокирующий».

Да, можно разделять вызовы и операции. Но это всё равно каждый раз объяснять надо. И к тому же, все вызовы получаются асинхронными, ведь между вызовом и возвратом хотя бы несколько наносекунд проходит.

«Блокирующий сопрограмму» /thread

/thread

У тебя есть личный опыт использования предлагаемой тобой терминологии?

Для пояснения опять нужен абзац текста, потому что все понимают слово «синхронный» по-разному.

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

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

Несомненно. Хоть целую страницу. Главное, чтобы не приходилось переобъяснять существующие термины.

Вот есть, к примеру, «фабрика». Если придумать своё какое-то значение, то во время объяснений никого поначалу не смутит это термин, он же понятен и так. Только вот понимать будут совсем не то. Возможно, в какой-то момент до кого-то дойдёт, что части не стыкуются. И тогда снова придётся объяснять и пояснять.

Я уже подзаколебался объяснять блокирующие вызовы, которые не блокируют выполнение нити. Каждый раз одно и то же, и каждый раз заново. Надеюсь, что новая терминология как-то поможет. Новое слово сразу вызывает вопрос о том, что это. И это как раз то, что нужно, чтобы избежать недопонимания.

Для Erlang и Racket используют: неблокирующий, блокирующий и блокирующий виртуальную машину.

Иногда синхронный, асинхронный и блокирующий виртуальную машину.

не большой специалист но выскажусь.
если текст программы вокруг этого вызова организован (и это допустим видно) исходя из того, что течение (flow) текста тут останавливается (именно текста программы, а не техн. деталей вроде того, отложит ли процессор этот тред или нет), то сказав async или non-blocking ты всех запутаешь. ведь ход текста на деле будет suspended, а ты им говоришь async
а если же написано async/non-blocking и там в тексте к примеру polling - тогда да, документация будет соответствовать увиденному.
есть еще один довод: если тебе лично покажут изолированно этот текст (где делается вызов), но не расскажут про существование софтварных недо-тредов, то как ты этот вызов будешь воспринимать?
ну или иначе. в программе с полноценными потоками вызовы блокируещие, но они на уровне терминов не становятся менее блокирующими от того факта, что у этого процесса есть и другие треды и на них процессор продолжает иногда переключаться и выполняет их, т.е. это отдельное обстоятельство/детали. иначе можно договориться, что в mutitasking компьютере вообще блокирующего ничего нет.
ну я так думаю. а про то, что nginx не остановится на это время наверное можно где-то примечания делать плюс в introduction объяснить. если есть такие вызовы, которые весь nginx остановят, то наверное тоже примечения делать, мол что весь webserver будет suspended и реквесты не будут served.
но это мое сугубо лично мнение.

ну и опять же смотря какая там фактическая семантика, если при запросе к примеру к БД у тебя на момент выполнения следующей строки текста программы данные уже гарантированно доступны (т.е. их прибытия ждали), то наверное это был не async и не non-blocking.

Если я тебя правильно понял, ты говоришь о той же путанице в терминологии. Я в курсе. Часто сталкиваюсь с этой путаницей в последнее время.

Я скорее о том, что это две области с четкой границей: execution flow на уровне текста программы - это одно, а треды, процессы, ОС, процессор - это другое. Если для execution flow на уровне текста программы этот вызов blocks, то возможно, его можно просто называть «blocking». Что до альтернативного термина: может быть поискать что-то вокруг слов control, flow, fiber, routine, execution, suspend.

В обоих случаях это блокирующие вызовы. В первом блокируется поток, во втором блокируется сопрограмма.

Вот уж набросил так набросил.

Откладывающийся, может.

В обоих случаях это блокирующие вызовы. В первом блокируется поток, во втором блокируется сопрограмма.

После объяснений это становится понятно. Но сначала на «блокирущий» вызов происходит мгновенная реакция: «не-е, нам нельзя блокироваться, у нас один поток. Всё колом встанет.»

Вот уж набросил так набросил.

В качестве наброса тема унылая донельзя.

Откладывающийся, может.

У меня свой вариант был похожий: «yielding call» или «уступающий вызов».

«Откладывающийся» тоже неплохо, но возникает вопрос о том, что дальше происходит, после откладывания.

на «блокирущий» вызов происходит мгновенная реакция: «не-е, нам нельзя блокироваться, у нас один поток. Всё колом встанет.»

Так оно и так колом встанет если одна сопрограмма. А если их много то как оно может колом встать? Это тоже многозадачность, хоть и кооперативная.

А еще есть такие понятия как конкурентность и многопоточность.

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

Либо нужно, чтобы у человека не было знаний о внутреннем устройстве вообще, и тогда ему можно рассказать, что вот есть потоки исполнения, в которых можно делать read/write. Они вернут управление только когда завершат работу. При этом можно создавать новые потоки исполнения в любой момент. Если не задумываться о деталях, то это вполне понятно.

Либо нужно детальное понимание механизма работы. Что происходит, когда, как.

Проблема в том, что у большинства детального понимания нет, а вместо этого они где-то посередине. Эти дополнительные знания не помогают, они мешают. Вместо того, чтобы выяснить, что в данном случае значит «блокирующий» или «асинхронный», используется существующее знание. Терминология конфликтует, и всё стопорится. Нужно этот недостаток понимания как-то преодолеть. И пока что самая лучшая идея состояла в введении новых названий.

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