Когда нечего сказать надо докопатся по пацански, да?

> На то, чтобы реализовать гринтреды в той модели, которая тебе нужна, с пулом потоков, с очередью задач, и прочим, тебе потребуется полгода. Год, если кроссплатформенно и оптимизировано на основе профайла под высокой нагрузкой.

Дорогой джун, это ваши фантазии :)
Как минимум профайлинг там вообще ни разу не упал, вы бы это знали, если бы хоть раз что то сами писали.
Насчёт реализаии я подумаю.

> То есть велосипедишь буферизированный ввод вывод? Как ты парсишь http в таком варианте? Вот распарсил ты "Accept-En", и буфер кончился, дальше ты копируешь Accept-En в начало буфера, и заказываешь чтение на хвост буфера? Ну-ну. Прикинь я из std получаю функцию readline, которая все эти штуки делает самостоятельно.

https://github.com/rozhuk-im/liblcb/blob/master/src/proto/ht...
вот так я это делаю.
В начале надо поймать crlfcrlf - маркер окончания заголовка, а уже потом парсить.
Ни std ни readline я не юзаю - нету в них смысла. Это инструменты уровня консольных утилит, чтобы по быстрому накодить приложуху которая работает меньше секунды и завершается.
А проблемы с внезаптным концом данных при парсинге - это детский сад, который у меня был в 2003 году.
Те вы мало того что пытаетесь мне сообщить о важности мытия рук перед едой, о которой сами недавно узнали, так ещё и не дошли до стадии что руки надо мыть с мылом - те парсить когда весь заголовок приедет.
Осталось дождаться когда вы сделаете важное открытие, что оказывается заголовок парсить не всегда нужно, а когда нужно, но это будет через пару лет, вы узнаете что там есть проверки валидности пришедшего согласно RFC.

> А вот большинству системных программистов интересна. Им интересно чтобы, в первую очередь, стабильно работало на linux'е, во-вторую очередь на bsd, в-третью очередь на прочих unix'ах, и для некоторых проектов ещё важна венда.

Какому большинству!?
Вашим двум однокурсникам?
Почему меня это должно волновать?
Чтобы вы знали, nginx на линухе поддерживается и пилится по такому же остаточному принципу, по крайней мере долгое время так было. И все новые фрёвые фичи даже с каррента уже юзаются в нгинхе.

> 1. Если я использую либы, это не значит, что я не понимаю как эти либы работают.
> 2. Мне нет нужды доказывать кому-то, что я понимаю как реализуются гринтреды посредством написания велосипеда гринтредов.

Ты палишься как зелёный джун в каждом посте, куда уж больше :)
Это я к тому что ты там собрался профилировать обвязку над kqueue()/epoll() - это просто дичь.
Хотя что взять с человека который обмазывается либами которые работают неведомым ему образом, ты же пихнёшь в обвязку чтото что тебе кажется простым а потом будешь с профайлером искать чего оно так тормозит. У крестовиков такое постоянно происходит: вроде написана очевидная штука а оказывается что она жестоко грузит проц ненужными действиями.

Я вот когда пользую ffmpeg, OpenCV - даже не стесняюсь признавать что я не понимаю как они работают, там тонны математики и десятки тысяч человеко/часов.

> Хаха. "Знание технологий". Если ты велосипедишь без уважительной причины, то это не "знание технологий", это "знание теории". Оторванность от практики уровня профессора расеянского вуза.

Звучит как будто вы с урока в туалет отпрашиваетесь - всё бы вам уважительные причины :)

Речь шла именно про знанение технологий с которыми работаешь.
Пока вы там со своим буферезированным std будете файл с диска по хттп отдавать перекладывая в сокет, я возьму sendfile(), и для tls приколхожу ядерную реализацию чтобы ядро само всё делало, по возможности используя аппаратный акселератор в железе.
Ну и фишка в том, что у меня msd проксирует потоки, и он тоже испольует sendfile() вместо обычного send(), тем самым экономя проц на копировании данных с юзерспейса в ядро, потому что в кольцевой буфер только один источник записи но потенциально куча читателей.
Этого всего нет и не будет ни в каких библиотеках, никаких растах.
Это именно низкоуровневый кодинг с использованием всех доступных фич ОС.
Так же как на линуксах делают магию со splice, каждый раз отдельно под каждую задачу.

Ну или упомянутые выше OpenCV - что вы там со своим знанием раста сделаете?
Соберёте тестовый пример?
OpenCV сам по себе "язык" по круче раста для работы с изображениями и видео, пофик с какого языка ты её юзаешь.

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

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

Правда имплементировать крипту мне нравится, я даже свою реализацию ECDSA сделал с нуля на С.
Там и математика полностью своя.
Можешь падать в обморок или бится истерике: С, криптография и не дипломированный специалист в области крипты в одном  решении сошлись.

Надо ради прикола в ваш раст своего С кода понакомитить, по больше, чтобы он помер по быстрее :))))