То есть к остальному сюжету исхода у вас вопросов нет, правильно понимаю?
Смысл разбирать сказки целиком? Достаточно разобрать содержащийся моральный посыл, который в данном случае заключается в "геноцид - это хорошо и правильно", чтобы понять всю вредность и окружающего текста тоже.
И почему вы решили это осуждать? В мире есть только ваша норма?
Моя? Она узаконена уголовными кодексами очень многих стран.
Мир тогда был довольно странным местом, хотя он во многом странный и сейчас, но это никак не отменяет и не умаляет умных мыслей подкрепленных аргументами.
Каких же? Что число Пи равно ровно трем? Библия содержит и такое место, да. Или что по закону больших чисел в ней найдется некоторое количество действительно чего-то хорошего? Так для этого можно воспользоваться другим источником, в котором они тоже найдутся, но без окружающей мразоты.
Никогда не слышал ничего глупее.
Как же у верцунов логика ломается, когда им показываешь логические нестыковки в их же священной книге...
Можно, но там вам все разжевали и объяснили, осталось лишь услышать. На постижение даже простых вещей, типо суры что я выше привел, у вас может и жизни не хватить.
Услышать например что? В приведенной суре мудрости нет вообще. Никакой. Там банальный нажим для подчинения под давлением, причем еще и с логической ошибкой "нет того, кроме" - вывод можно было бы сделать разве что "в данное время это божество сильнее других".
Кстати, там это где, в Торе, Библии и Коране? Я правильно понял?
Да, в источниках авраамических религий.
это малеха жесть
Не "малёха", а там очень много жести, такой, что нормальный человек прочитает и скажет - "да ведь этот Яхве просто конченый мудак и садист".
Ну например, когда так называемый господь послал евреев вырезать всех в земле Ханаанской, т.е. устроить геноцид. И такое делалось неоднократно. Или когда Мухаммед женился на 9-летней. Примеров очень много, лезть перечитывать лень. И да, в свете "не может быть от дерева доброго плода худого" это получается не мудрость нифига, и не ценная. Во всяком случае, не найдется там действительно мудрости, которую нельзя было бы получить из иного, не зашкваренного источника.
От действий Израиля гибнет гораздо больше людей, чем от действий России на Украине, фактически Израиль оправдывает и устраивает геноцид, но почему-то против него, например, никто не вводит санкции, а против России - валом.
Сенсация! Питон наконец додумался сделать то, что в Perl и Tcl/Tk было десятилетиями! Не прошла и четверть века!
Разобрались: вот что на самом деле такое "интерпретатор".
Тут смешно. "Вот видите функцию. Вот она-то и запускает интерпретатор. Вот, а там состояния интерпретатора. Вот мы и разобрались, что такое интерпретатор 😂" - человек, который не понимал, что такое интерпретатор, так и не поймет.
Баферы
А тут каждый раз режет слух. Слово "буфер" в русском языке появилось задолго до IT.
Оно уже не один год новое. Поздние советы - просто остров свободы по сравнению с: ни досмотров в аэропортах, ни покупки билетов по паспорту (просто захотел, взял и поехал куда угодно), ни биометрии, ни камер понатыканных...
Ну нет. Планшет - это такая прямоугольная штуковина, на которой можно закрепить лист бумаги. Например, чтобы на нём порисовать. Или если назначение другое, на этой бумаге уже может быть, например, карта. А в чем именно футуризм, сказано в самом посте.
но согласись, что в этом случае резко упрощается учёт потраченных ресурсов, для всех сторон. В случае kevent, как увидеть количество, например, таймеров, навешенных на одну конкретную kqueue, процессов, и т.д.? Видеть их всех в виде дескрипторов - просто и достаточно надёжно, то есть вполне себе юниксовый подход "всё есть файл".
Хм, не думал с этой стороны, аргумент (правда, среди fd этот учет самому надо вести, нет ведь енумераторных сисколлов). Однако тут, конечно, уши примитивности юниксового подхода торчат (доведенного в Plan9 до абсурда) - в винде были бы соответствующие API для получения, они не связаны абстракцией файла, ну и какой-нибудь WaitForMultipleObjects в качестве образца для kqueue мог бы еще и мьютексы ждать, например. С другой стороны, местами изначальные архитектурные косяки юникса всё же потихоньку правят - то переход на libxo начали, то вот недавно расширенные errno втащили (второй аргумент конечно лимитирован размером, но всё же большой шаг вперёд)...
То есть мало того что переложили на юзера, заставив его агрегировать чанки, так ещё и всё равно не дали регулировки по потокам.
Ну а что ты хочешь, backward compatibility, я ж сказал - ничего выдающегося не добавили, просто из "совсем жопы" сделали "так себе" - по крайней мере HoL от потери пакетов оно в ряде случаев устранит.
Я тут, конечно, ужален проблемами одного почти провального проекта, где из-за аналогичной глупости в Erlang оказалось практически нереально обеспечить стабильный поток проходящих данных, и дую на воду, но для меня теперь вариант "хлебай что дают из пожарного шланга", который реализуется таким подходом, не подходит для чего-то серьёзнее песочницы.
О, я тут последние полмесяца постом «Что не так с ООП в 2025» и комментами под ним (жаркий срач вышел) сподвигся наконец осилить туториал по Эрлангу. Честно говоря, он меня разочаровал - написано плохо, без объяснения многих моментов, даже строк нет, функицональщина (иммутабельность) непонятно зачем, как-то коряво выглядит. Так что дочитывал я уже без запуска примеров. Меня просто привлекает акторная модель (на самом деле изначальное ООП с сообщениями, да хоть netgraph, ну ты в курсе), а автор поста заявил, что этот позволяет обходиться без мьютексов. А у меня в мета-проекте, кроме протокола, еще задача специализированного безопасного языка, который можно было бы сунуть в ядро или передать на удаленный сервер - и вот познакомившись с eBPF/XDP, долго плевался, багу в шланге заводил, нифига оно толком непригодное было для задачи системы от защиты от DDoS-атак, которая у меня стояла (там даже чистку conntrack единым таймером не сделать, ни к черту вообще). Даже начинал собственный BPF64, но потом бросил - подход ассемблеров, похоже, в корне ошибочный.
В общем, я спросил там автора поста, как бы он делал систему на сто миллионов в conntrack'е акторной моделью (у меня в голове, конечно, кластер машин по типу pfsync/carp но с И отказоустойчивостью, И балансировкой нагрузки), челлендж ему понравился, но ответа пока нет :)
Приходи туда тоже, будет интересно почитать про эти проблемы эрланга детальнее с теми, кто его ел.
(Там было ещё хуже: один вход у "процесса" на всё включая канал регулировки. Тут хотя бы можно назад передавать сообщения типа "добавляю окно на 100кбайт для потока 8" и они могут быть прочтены вперёд собственно данных.)
Что, и тут всё плохо? Там рекламировали Akka.NET, я посмотрел их сайт, бросил как раз после описаний TCP-взаимодействия, имён мэйлбоксов и т.д. Мне-то больше подход MQTT по душе (он кстати в 5.0 вполне взрослый для хайлоадного RPC - response topics, все дела). Видимо, опять придется посмотреть у функциональщиков (в данном случае эрлангив) способы реализации и делать на более мейнстримных языках фреймворки...
Если один буфер на все потоки - это уже не то, что нужно. Нужны раздельные.
Нет, это зависит от приложения. Даже в QUIC у тебя не один, а два типа присылаемых апдейтов буфера - не только на конкретный поток, но и на всё соединение. Ну ниже рассмотрим.
Повторюсь, если этого нет, то фактически нет разницы с тем, что просто в одном потоке тегировали каждое сообщение ещё и одним байтиком перед ним (или в userdata уложили тот тег). Заодно и деление на чанки точно так же делается на уровне юзера, в пределах того же соединения.
Это для программиста приложения разницы нет, и то с точки зрения написания кода, а не поведения - а с точки зрения транспортного уровня разница колоссальная. Перенос стримов и фрейминга с уровня приложения на L4 позволяет добиться очень многого - во-первых, тот самый HoL, во-вторых - и это куда более важно - транспортный уровень может оптимизировать доставку, зная, сколько в этом сообщении будет байт, и тот факт, что получателю нет смысла получать сообщение по кускам. Первым делом, это multipath - сколько с ним бьются в TCP, всё без толку, QUIC не стал и пытаться. А с делением на сообщения мы просто берем - при установившихся стабильных SRTT, RTTvar, cwnd - и по алгоритму из Multilink PPP отправляем куски по разным путям с их скоростями так, что они приезжают вместе. Далее, извечная проблема tcp reordering, которой вообще-то быть не должно в принципе, а мы должны иметь возможность делать round-robin balancer'ы - дык вот, я пока что думаю, что она решается очень простым алгоритмом получателя "если есть дыра, и самый свежий прибывший чанк не последний в сообщении (нет флага E), то задержать SACK на величину RTTvar отправителя". А свой RTTvar он нам регулярно сообщает (обо всём этот в QUIC, конечно, не подумали, да там даже unordered нет...). Уже эти две вещи дадут гигантский прогресс, кмк.
А вот реально раздельное управление потоком по всем потокам (русский тут чего-то зажат в омонимию, per-stream flow control) ты на одном соединении не сделаешь, тут что TCP что SCTP надо сейчас несколько порождать, а тогда ещё и заботиться, чтобы пришло именно на нужный серверный процесс, указать серверу, что это соединение надо ставить в комплект вот этому... марудно. Вот потому, я так понимаю, и стали запускать SPDY с потомками - когда поняли, что от последней попытки (SCTP) ждать хорошего всё равно нельзя.
Да, это иронично (впрочем чего ожидать от телефонистов?..), только Гугл показал, что не умеет в протоколы. Оно как бы не хуже SCTP вышло-то. Особенно вот этот цирк с неумением в sequence number arithmentics с компрессией номеров пакетов, которым легко устроить DoS пира (гугл толстый, ему всё равно, а вот остальным...)
Я честно не понял ещё смысла в этом навороте. Поищу при случае.
Ну см. на https://pdos.csail.mit.edu/archive/uia/sst/ картинку - она красивая :) Хочу, например, костыль SSH для stderr обобщить просто дочерними потоками в дереве. Как минимум, вновь открываемый поток должен borrow'ить окно у своего родителя - иначе нам что, бесконечно буфера добавлять? Правда, дальше этой идеи они не специфицировали, увы :( Да, в имеющихся системах, что QUIC, что SSH2, имеют на каждый поток отдельное окно - потому что так проще в реализации. Но моя техническая интуиция говорит мне, что нужно более комплексное решение - и в HTTP/2 например пытались же делать дерево потоков. В конце концов, если в названии протокола Stream Control, надо соответствовать :) а "просто как пачка tcp" на это не тянет - в конце концов, при общем congestion control мы можем использовать эффективнее, хоть WFQ, и должны это делать в условиях ограничений, на которых мой протокол пытается выживать, например... собственно, вот да - допустим у тебя сто или тысяча потоков, обновлять rwnd каждого будет неприлично chatty, если этого не требуется, а полоса scarce.
Попробую придумать пример... Ну, поскольку делается оно для помеси мессенджера с соцсетями, возьмем в пример Telegram. Допустим, мы чатимся, и в это время слушается музыка и качаются файлы. Понятно, приоритет отдадим тексту, но музыке незачем ограничивать окно вообще (чтоб заикалась, если ACK потеряется), а файлам всем дать общее окно - всё равно пишущий их тред упирается в скорость HDD, а какой из них быстрее скачается, какая разница. Тут, понятно, и дескрипторы бы отдельные, да не все (то есть треду наверное хватит одного для сразу нескольких потоков), но тут наверное сложно в реализации, не придумаю сходу (что-то вроде peeloff из поддерева, штоль).
Заметки тоже почитаю.
Да, меня пока еще никто толком не поревьювил, к сожалению. Правда, тамошняя свалка этому способствует :) Я бы вот, например, всё хотел объединить все типы потоков в единый - сейчас у меня как бы три типа, bytestream (tcp-like) channel'ы (наподобие SSH) и два делящихся на сообщения, ordered и unordered (как в SCTP), плюс id'ы сообщений чтоб опциональная докачка сообщений при обрыве (если QoS>0 как в MQTT - да, мы сессионый протокол, L5). Но взаимно управлять потоками удобнее, когда вот у него просто номер: 1, 2... и эти номера не делятся дополнительно на типы (но суть unordered в том, что он именно что в том же потоке логически, как решение URG/^C telnet). Как это втиснуть в SOCK_STREAM/SOCK_DGRAM, если выделять отдельные fd вообще не представляю. Если нет.. всё вопрос красивости единого API стоит. В SSH2 интересно сделали, там channel'ы byte-oriented, хотя и делятся на чанки ниже уровнем, и в них возможны request'ы/reply синхронные - то есть дочитали до байта, тут раз, сообщение целиком (как бы переключение, но нет, эдакий URG отдельный большого размера), потом снова просто байты будут. Но там просто луп в коде парсит сообщения и сразу обрабаттывает, им там до теоретической вынесенности и красивости API нет дела, они уже и так на L7...
Совершенно неверно. Не надо путать "специально извратиться, чтоб обойти защиту" (аналог - существует такой IOCCC, соревнования по самому запутанному коду, в проде разумеется так никто делать не будет) и "допустить ошибку случайно". Вот с мьютексами допустить ошибки случайно - как нефиг делать. И даже опытные программисты, даже системщики в ядрах, всё равно время от времени напарываются и чинят дедлоки и пр.
А как у нас с многопоточностью этого огромного switch/case ?Вроде с этого требования начинали.
А, я забыл, что после коммента про Go надо было не отвечать. Как можно было забыть, что каждый "огромный switch/case", то есть актор, живёт в своем отдельном (green) треде, не понимаю, если уж "с этого начинали".
И что в ней сильного, если Erlang предлагает гораздо лучше, причем задолго до появления Go? Типа хоть что-то в языке не убогое, а "норм" ? Ну если только так.
Поищите на сайте ООН, достаточно неангажированный источник? Во всяком случае, когда Израиль назвал ООН антисемитской организацией, было очень смешно.
Смысл разбирать сказки целиком? Достаточно разобрать содержащийся моральный посыл, который в данном случае заключается в "геноцид - это хорошо и правильно", чтобы понять всю вредность и окружающего текста тоже.
Моя? Она узаконена уголовными кодексами очень многих стран.
Каких же? Что число Пи равно ровно трем? Библия содержит и такое место, да. Или что по закону больших чисел в ней найдется некоторое количество действительно чего-то хорошего? Так для этого можно воспользоваться другим источником, в котором они тоже найдутся, но без окружающей мразоты.
Как же у верцунов логика ломается, когда им показываешь логические нестыковки в их же священной книге...
Услышать например что? В приведенной суре мудрости нет вообще. Никакой. Там банальный нажим для подчинения под давлением, причем еще и с логической ошибкой "нет того, кроме" - вывод можно было бы сделать разве что "в данное время это божество сильнее других".
Да, в источниках авраамических религий.
Не "малёха", а там очень много жести, такой, что нормальный человек прочитает и скажет - "да ведь этот Яхве просто конченый мудак и садист".
Я вот лучше альтернативный взгляд подкину https://old.lah.ru/text/sklyarov/baal-text.htm для открытия глаз и включения мозгов, такскать.
Ну например, когда так называемый господь послал евреев вырезать всех в земле Ханаанской, т.е. устроить геноцид. И такое делалось неоднократно. Или когда Мухаммед женился на 9-летней.
Примеров очень много, лезть перечитывать лень. И да, в свете "не может быть от дерева доброго плода худого" это получается не мудрость нифига, и не ценная. Во всяком случае, не найдется там действительно мудрости, которую нельзя было бы получить из иного, не зашкваренного источника.
От действий Израиля гибнет гораздо больше людей, чем от действий России на Украине, фактически Израиль оправдывает и устраивает геноцид, но почему-то против него, например, никто не вводит санкции, а против России - валом.
Это религиозные-то книжки "хорошие" ? Да там огромное количество морально-отвратительных вещей делаются "хорошими" персонажами.
Вообще-то нет. У слова "норма" два значения, второе - "как должно быть". И в медицине применяют второе.
Может, потому что категорическй императив Канта нежизнеспособен? Ну и кстати, для 97% граждан работало.
В оригинале организационные, и было это известно задолго до возникновения Хабра.
А что непонятного, Израиль за те же действия, и даже куда хлеще, не наказывают, а Россию наказывают.
Растровый.
Сенсация! Питон наконец додумался сделать то, что в Perl и Tcl/Tk было десятилетиями! Не прошла и четверть века!
Тут смешно. "Вот видите функцию. Вот она-то и запускает интерпретатор. Вот, а там состояния интерпретатора. Вот мы и разобрались, что такое интерпретатор 😂" - человек, который не понимал, что такое интерпретатор, так и не поймет.
А тут каждый раз режет слух. Слово "буфер" в русском языке появилось задолго до IT.
"Гыгы, Бивис..."
Точно, а внутриэлитные конфликты уже отменили.
Наоборот. Оттуда сюда не захочется возвращаться.
Оно уже не один год новое. Поздние советы - просто остров свободы по сравнению с: ни досмотров в аэропортах, ни покупки билетов по паспорту (просто захотел, взял и поехал куда угодно), ни биометрии, ни камер понатыканных...
Ну нет. Планшет - это такая прямоугольная штуковина, на которой можно закрепить лист бумаги. Например, чтобы на нём порисовать. Или если назначение другое, на этой бумаге уже может быть, например, карта. А в чем именно футуризм, сказано в самом посте.
Хм, не думал с этой стороны, аргумент (правда, среди fd этот учет самому надо вести, нет ведь енумераторных сисколлов). Однако тут, конечно, уши примитивности юниксового подхода торчат (доведенного в Plan9 до абсурда) - в винде были бы соответствующие API для получения, они не связаны абстракцией файла, ну и какой-нибудь WaitForMultipleObjects в качестве образца для kqueue мог бы еще и мьютексы ждать, например. С другой стороны, местами изначальные архитектурные косяки юникса всё же потихоньку правят - то переход на libxo начали, то вот недавно расширенные errno втащили (второй аргумент конечно лимитирован размером, но всё же большой шаг вперёд)...
Ну а что ты хочешь, backward compatibility, я ж сказал - ничего выдающегося не добавили, просто из "совсем жопы" сделали "так себе" - по крайней мере HoL от потери пакетов оно в ряде случаев устранит.
О, я тут последние полмесяца постом «Что не так с ООП в 2025» и комментами под ним (жаркий срач вышел) сподвигся наконец осилить туториал по Эрлангу. Честно говоря, он меня разочаровал - написано плохо, без объяснения многих моментов, даже строк нет, функицональщина (иммутабельность) непонятно зачем, как-то коряво выглядит. Так что дочитывал я уже без запуска примеров. Меня просто привлекает акторная модель (на самом деле изначальное ООП с сообщениями, да хоть netgraph, ну ты в курсе), а автор поста заявил, что этот позволяет обходиться без мьютексов. А у меня в мета-проекте, кроме протокола, еще задача специализированного безопасного языка, который можно было бы сунуть в ядро или передать на удаленный сервер - и вот познакомившись с eBPF/XDP, долго плевался, багу в шланге заводил, нифига оно толком непригодное было для задачи системы от защиты от DDoS-атак, которая у меня стояла (там даже чистку conntrack единым таймером не сделать, ни к черту вообще). Даже начинал собственный BPF64, но потом бросил - подход ассемблеров, похоже, в корне ошибочный.
В общем, я спросил там автора поста, как бы он делал систему на сто миллионов в conntrack'е акторной моделью (у меня в голове, конечно, кластер машин по типу pfsync/carp но с И отказоустойчивостью, И балансировкой нагрузки), челлендж ему понравился, но ответа пока нет :)
Приходи туда тоже, будет интересно почитать про эти проблемы эрланга детальнее с теми, кто его ел.
Что, и тут всё плохо? Там рекламировали Akka.NET, я посмотрел их сайт, бросил как раз после описаний TCP-взаимодействия, имён мэйлбоксов и т.д. Мне-то больше подход MQTT по душе (он кстати в 5.0 вполне взрослый для хайлоадного RPC - response topics, все дела). Видимо, опять придется посмотреть у функциональщиков (в данном случае эрлангив) способы реализации и делать на более мейнстримных языках фреймворки...
Нет, это зависит от приложения. Даже в QUIC у тебя не один, а два типа присылаемых апдейтов буфера - не только на конкретный поток, но и на всё соединение. Ну ниже рассмотрим.
Это для программиста приложения разницы нет, и то с точки зрения написания кода, а не поведения - а с точки зрения транспортного уровня разница колоссальная. Перенос стримов и фрейминга с уровня приложения на L4 позволяет добиться очень многого - во-первых, тот самый HoL, во-вторых - и это куда более важно - транспортный уровень может оптимизировать доставку, зная, сколько в этом сообщении будет байт, и тот факт, что получателю нет смысла получать сообщение по кускам. Первым делом, это multipath - сколько с ним бьются в TCP, всё без толку, QUIC не стал и пытаться. А с делением на сообщения мы просто берем - при установившихся стабильных SRTT, RTTvar, cwnd - и по алгоритму из Multilink PPP отправляем куски по разным путям с их скоростями так, что они приезжают вместе. Далее, извечная проблема tcp reordering, которой вообще-то быть не должно в принципе, а мы должны иметь возможность делать round-robin balancer'ы - дык вот, я пока что думаю, что она решается очень простым алгоритмом получателя "если есть дыра, и самый свежий прибывший чанк не последний в сообщении (нет флага E), то задержать SACK на величину RTTvar отправителя". А свой RTTvar он нам регулярно сообщает (обо всём этот в QUIC, конечно, не подумали, да там даже unordered нет...). Уже эти две вещи дадут гигантский прогресс, кмк.
Да, это иронично (впрочем чего ожидать от телефонистов?..), только Гугл показал, что не умеет в протоколы. Оно как бы не хуже SCTP вышло-то. Особенно вот этот цирк с неумением в sequence number arithmentics с компрессией номеров пакетов, которым легко устроить DoS пира (гугл толстый, ему всё равно, а вот остальным...)
Ну см. на https://pdos.csail.mit.edu/archive/uia/sst/ картинку - она красивая :) Хочу, например, костыль SSH для stderr обобщить просто дочерними потоками в дереве. Как минимум, вновь открываемый поток должен borrow'ить окно у своего родителя - иначе нам что, бесконечно буфера добавлять? Правда, дальше этой идеи они не специфицировали, увы :( Да, в имеющихся системах, что QUIC, что SSH2, имеют на каждый поток отдельное окно - потому что так проще в реализации. Но моя техническая интуиция говорит мне, что нужно более комплексное решение - и в HTTP/2 например пытались же делать дерево потоков. В конце концов, если в названии протокола Stream Control, надо соответствовать :) а "просто как пачка tcp" на это не тянет - в конце концов, при общем congestion control мы можем использовать эффективнее, хоть WFQ, и должны это делать в условиях ограничений, на которых мой протокол пытается выживать, например... собственно, вот да - допустим у тебя сто или тысяча потоков, обновлять rwnd каждого будет неприлично chatty, если этого не требуется, а полоса scarce.
Попробую придумать пример... Ну, поскольку делается оно для помеси мессенджера с соцсетями, возьмем в пример Telegram. Допустим, мы чатимся, и в это время слушается музыка и качаются файлы. Понятно, приоритет отдадим тексту, но музыке незачем ограничивать окно вообще (чтоб заикалась, если ACK потеряется), а файлам всем дать общее окно - всё равно пишущий их тред упирается в скорость HDD, а какой из них быстрее скачается, какая разница. Тут, понятно, и дескрипторы бы отдельные, да не все (то есть треду наверное хватит одного для сразу нескольких потоков), но тут наверное сложно в реализации, не придумаю сходу (что-то вроде peeloff из поддерева, штоль).
Да, меня пока еще никто толком не поревьювил, к сожалению. Правда, тамошняя свалка этому способствует :) Я бы вот, например, всё хотел объединить все типы потоков в единый - сейчас у меня как бы три типа, bytestream (tcp-like) channel'ы (наподобие SSH) и два делящихся на сообщения, ordered и unordered (как в SCTP), плюс id'ы сообщений чтоб опциональная докачка сообщений при обрыве (если QoS>0 как в MQTT - да, мы сессионый протокол, L5). Но взаимно управлять потоками удобнее, когда вот у него просто номер: 1, 2... и эти номера не делятся дополнительно на типы (но суть unordered в том, что он именно что в том же потоке логически, как решение URG/^C telnet). Как это втиснуть в SOCK_STREAM/SOCK_DGRAM, если выделять отдельные fd вообще не представляю. Если нет.. всё вопрос красивости единого API стоит. В SSH2 интересно сделали, там channel'ы byte-oriented, хотя и делятся на чанки ниже уровнем, и в них возможны request'ы/reply синхронные - то есть дочитали до байта, тут раз, сообщение целиком (как бы переключение, но нет, эдакий URG отдельный большого размера), потом снова просто байты будут. Но там просто луп в коде парсит сообщения и сразу обрабаттывает, им там до теоретической вынесенности и красивости API нет дела, они уже и так на L7...
Это, примерно, управление ядерным реактором или химическим производством
на винде.Совершенно неверно. Не надо путать "специально извратиться, чтоб обойти защиту" (аналог - существует такой IOCCC, соревнования по самому запутанному коду, в проде разумеется так никто делать не будет) и "допустить ошибку случайно". Вот с мьютексами допустить ошибки случайно - как нефиг делать. И даже опытные программисты, даже системщики в ядрах, всё равно время от времени напарываются и чинят дедлоки и пр.
А, я забыл, что после коммента про Go надо было не отвечать. Как можно было забыть, что каждый "огромный switch/case", то есть актор, живёт в своем отдельном (green) треде, не понимаю, если уж "с этого начинали".
И что в ней сильного, если Erlang предлагает гораздо лучше, причем задолго до появления Go? Типа хоть что-то в языке не убогое, а "норм" ? Ну если только так.